OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 24, 2017 10:05 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Abstracting IPC "Services "
PostPosted: Tue Nov 29, 2016 11:32 am 
Offline
Member
Member

Joined: Sat Nov 07, 2015 3:12 pm
Posts: 127
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


Top
 Profile  
 
 Post subject: Re: Abstracting IPC "Services "
PostPosted: Wed Nov 30, 2016 12:37 am 
Offline
Member
Member
User avatar

Joined: Sun Feb 09, 2014 7:11 pm
Posts: 56
Location: Within a meter of a computer
Are you referring to something like android's /dev/binder ?

_________________
"If the truth is a cruel mistress, than a lie must be a nice girl"
Working on Cardinal
Find me at #Cardinal-OS on freenode!


Top
 Profile  
 
 Post subject: Re: Abstracting IPC "Services "
PostPosted: Sat Dec 03, 2016 10:27 am 
Offline
Member
Member

Joined: Sat Nov 07, 2015 3:12 pm
Posts: 127
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)


Top
 Profile  
 
 Post subject: Re: Abstracting IPC "Services "
PostPosted: Tue Dec 13, 2016 10:02 am 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1061
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.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Abstracting IPC "Services "
PostPosted: Sat Dec 17, 2016 7:17 pm 
Offline
Member
Member

Joined: Sat Nov 21, 2009 5:11 pm
Posts: 639
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group