shared memory ipc with dynamically linked code
Posted: Sun Aug 12, 2007 8:29 am
The more I think about it the more is sounds like com...
I am making a microkernel and each driver and service (such as the window manager) are user mode processes. Every process will most definatly at least have to request a window (or maybe I should come up with a new term here) interface if it wants to interact with the gui. The gui itself is a process that request interfaces from the graphics driver service who finally draws the end result bitmap containing the window.
Lets say someone wants to make a graphics driver for my os. They must at least implement my os's generic interface for sending bitmaps to the graphics device. If they wanted to, they could also throw in maybe a opengl interface or even some ultra secret proprietary interface. As long as the process requesting such an interface from the parent process knows before hand the format of the interface it can use it.
A process thats already loaded (like a service or device driver) registers a ID and version # to identify an interface that can be used by another process for data sharing and communication without using a interrupts or system calls (except using one to request or register an interface).
The process requesting an interface already knows the format and uses a software interrupt to request this interface.
The kernel checks a list of interfaces and if it finds a match for interface id and version number it returns with a positive response in the form of a non null pointer pointing to the start of the shared page in its address space.
The interface has its first 4 bytes zeroed to indicate not ready and the next 8 bytes contain the offset in the requesting process's address space for the start of this page.
The process that registered the interface also had the shared page mapped into its address space earlier, a message is sent to the interface process telling it to fill out the interface.
The process waits until the last moment (after filling it out) to set the given interface id and version in oder to tell the other process its ready for use.
The remainder of the page is used for shared code and data. The interface process uses the offset field to apply them to the pointers in the interface that point to items in the shared page.
The requesting process polls the interface id, version number, and offset until they are nonzero (in a low priority way so it should do other useful things while waiting) and when those 2 fields are filled in it can use the interface.
The interface contains a base structure with the mandatory first 12 bytes used for id and version, while the remainder can be used for whatever.
The structure can contain pointers together structures, routines, and data that resides in the remainder of the shared page.
The requesting process uses the routines provided in the interface to operate on shared data in the interface itself or residing anywhere in the shared page.
The interface parent process can read and write to the shared page therefor making an asynchronous communication loop that doesn't involve context switching, but each process must wait until its task switched in to operate on the shared page (of course).
Do you think this sounds good?
I am making a microkernel and each driver and service (such as the window manager) are user mode processes. Every process will most definatly at least have to request a window (or maybe I should come up with a new term here) interface if it wants to interact with the gui. The gui itself is a process that request interfaces from the graphics driver service who finally draws the end result bitmap containing the window.
Lets say someone wants to make a graphics driver for my os. They must at least implement my os's generic interface for sending bitmaps to the graphics device. If they wanted to, they could also throw in maybe a opengl interface or even some ultra secret proprietary interface. As long as the process requesting such an interface from the parent process knows before hand the format of the interface it can use it.
A process thats already loaded (like a service or device driver) registers a ID and version # to identify an interface that can be used by another process for data sharing and communication without using a interrupts or system calls (except using one to request or register an interface).
The process requesting an interface already knows the format and uses a software interrupt to request this interface.
The kernel checks a list of interfaces and if it finds a match for interface id and version number it returns with a positive response in the form of a non null pointer pointing to the start of the shared page in its address space.
The interface has its first 4 bytes zeroed to indicate not ready and the next 8 bytes contain the offset in the requesting process's address space for the start of this page.
The process that registered the interface also had the shared page mapped into its address space earlier, a message is sent to the interface process telling it to fill out the interface.
The process waits until the last moment (after filling it out) to set the given interface id and version in oder to tell the other process its ready for use.
The remainder of the page is used for shared code and data. The interface process uses the offset field to apply them to the pointers in the interface that point to items in the shared page.
The requesting process polls the interface id, version number, and offset until they are nonzero (in a low priority way so it should do other useful things while waiting) and when those 2 fields are filled in it can use the interface.
The interface contains a base structure with the mandatory first 12 bytes used for id and version, while the remainder can be used for whatever.
The structure can contain pointers together structures, routines, and data that resides in the remainder of the shared page.
The requesting process uses the routines provided in the interface to operate on shared data in the interface itself or residing anywhere in the shared page.
The interface parent process can read and write to the shared page therefor making an asynchronous communication loop that doesn't involve context switching, but each process must wait until its task switched in to operate on the shared page (of course).
Do you think this sounds good?