Abstracting IPC "Services "
Posted: Tue Nov 29, 2016 11:32 am
Hi,
I'm designing my micro kernel based OS.
in my OS, I want process to " implement IPC interfaces" an IPC interface is a contract.
For example, a "drive device driver " interface is a contract which guarantee that the process implementing it accepts messages like " getDriveSize, readDriveAt"
That same process can also implement other interfaces like "cacheHolder" managing messages like " flush Cache"
Each message will have their own encoding, headers and type.
How do you manage to avoid collisions with those messages and interfaces ?
I have thought about having interfaces UUID and short messages types, specific by interfaces .
But I am not satisfied:
- You never know how much randomly picked will be the UUID . If I were doing a proprietary OS I could give those using a well known authority. Not doing that.
- You need to " resolve " interfaces before sending messages to a process.
- I don't know yet how to manage versions
What do you do in your kernel ?
Regards,
Boris
I'm designing my micro kernel based OS.
in my OS, I want process to " implement IPC interfaces" an IPC interface is a contract.
For example, a "drive device driver " interface is a contract which guarantee that the process implementing it accepts messages like " getDriveSize, readDriveAt"
That same process can also implement other interfaces like "cacheHolder" managing messages like " flush Cache"
Each message will have their own encoding, headers and type.
How do you manage to avoid collisions with those messages and interfaces ?
I have thought about having interfaces UUID and short messages types, specific by interfaces .
But I am not satisfied:
- You never know how much randomly picked will be the UUID . If I were doing a proprietary OS I could give those using a well known authority. Not doing that.
- You need to " resolve " interfaces before sending messages to a process.
- I don't know yet how to manage versions
What do you do in your kernel ?
Regards,
Boris