Vincent Rivière skreiv:
The VDI, as any other system library, could be seen as some kind of shared library.
Called via the trap-mechanism?
Each library interface could be materialized by a list of pointer to functions. First a client program would have to get a pointer to that interface, then to call the required function though its offset.
But what about already existing applications? You would need to keep both interfaces.
That libraries could be designed to be run from user programs or from the kernel.By the way, does the kernel have to call the VDI ?
I see where you're going. No, the AES could be split into a server (for synchronising, event handling etc) and a client library (for drawing and interacting with objects and perhaps windows). I remember this discussion, and I like the concept. However, it didn't happen this way, and I don't think that we need to change the OS radically now that there's fewer developers than ever.
GEM apps call the VDI and AES through a trap. They will always do this. So it makes sense to implement the AES like it is now, and implementing the VDI in the kernel is a natural progression. Then there will only be one AES/VDI trap handler, and the AES - which I would guess does the majority of VDI calls - don't have to call the VDI via the trap interface. And the VDI implementation might even be simpler, since one can reuse e.g. locking mechanisms that already exists in the kernel.
Jo Even