OSDev.org
https://forum.osdev.org/

Abstracting IPC "Services "
https://forum.osdev.org/viewtopic.php?f=15&t=31039		 Page 1 of 1
Author:  Boris [ Tue Nov 29, 2016 11:32 am ]
Post subject:  Abstracting IPC "Services "
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
Author:  hgoel [ Wed Nov 30, 2016 12:37 am ]
Post subject:  Re: Abstracting IPC "Services "
Are you referring to something like android's /dev/binder ?
Author:  Boris [ Sat Dec 03, 2016 10:27 am ]
Post subject:  Re: Abstracting IPC "Services "
Indeed, it really looks like i'm designing something like this !
I still dont know in the long term, what is better, UUIDs (like microsoft COM ) or names..
Names are seems to reduce the probability of two people choosing the same identifier ; but two dumb people can always choose a generic name like "Controller" "Manager" and hop you have a collision.
But names will be slower to handle (you have to store/compare a variable-length ID)
Author:  onlyonemac [ Tue Dec 13, 2016 10:02 am ]
Post subject:  Re: Abstracting IPC "Services "
I'd do something like the following:
  • Identify each IPC process by name.
  • Generate a unique ID for each process when it is first created. This ID doesn't need to be persistent but is unique to each session. Simplest way is to start at 1 and increment each time a process is created. You may want to reuse IDs; there are pros and cons to both.
  • Require each process to implement a "getInterfaceVersion" for each interface that it implements (e.g. "getDriveDeviceDriverInterfaceVersion", "getCacheHolderInterfaceVersion", etc.) so that when you change the interfaces you can determine which interface version to use and switch to a "backwards compatibility" mode where you implement newer functions in the kernel, where possible, or disable certain functionality if the process doesn't support it.
Author:  Gigasoft [ Sat Dec 17, 2016 7:17 pm ]
Post subject:  Re: Abstracting IPC "Services "
UUIDs generated using the method described in RFC 4122 have an astronomically low chance of collisions, compared to human made names. However, in actuality you only need one unique ID per issuing authority. A simple way to generate such an unique ID would be to concatenate the issuer's country ID with their organization number or SSN (or equivalent). A random bit string can then be concatenated and the result passed through an one-way function. This is the only ID that needs to be resolved. It can then be combined with a small integer to uniquely identify a specific interface. There can also be a range reserved for well-known authorities that don't need to be resolved.
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/