OSDev.org

I'm currently looking into an IPC method for a microkernel based OS.

All processes, drivers, etc, are running in userspace and mapped to the same linear address (0x0).

I would absolutely love it if userProcessA could send a message to userProcessB without actually envoking a context switch/swap to supervisor mode to facilitate delivery of the message.

One method to do this, I thought, would be to use shared memory. Message queues would be mapped into every processes memory space and so userspace code could perform the messageQueue receive/send and the OS would only need to be envoked if a receive was called on an empty queue (or, potentially, on a send to a full queue).

I can see a couple problems to this approach, right off the bat:
1. any user app can access (and potentially overwrite and destroy) every message queue.
2. a special area of memory must be devoted to each apps linear address space, whether it uses IPC or not (takes away from memory the app could otherwise use).

I'd like to know, however, if there are more blantant holes to this approach, and if there are suggests on how to overcome these limitations?

Is it even feasable to try to make a fully userspace IPC solution?

I suppose the queue could be specifically mapped only into the address spaces that are interested in it. This would require each app to manually map it into their space via some shared memory Id, I would imagine.

Any ideas on this would be greatly appreciated.

--Jeff

well, you might have only queues that process can write to present in one process (plus queues it can read, but this time in read-only mode)... conceptually, that's still shared memory but a bit more "managed".

Also, you might insist on the fact that if N process access to the same destination, they'll each have their own queue, so that they won't mess with other process'queues.

The "real" problem comes from synchronization: you say "i'll call kernel only if queue is empty" ... that's nice, but what tells you noone (on another CPU, or due to an interrupt) isn't filling your queue right at the moment you're about to call kernel to sleep ? and if that's the case, isn't there a risk that you never get noticed of the new item's presence ?

Esp. if your sender code looks like "on message_add, if queue_is_found_empty then wakeup_queue_owner", it may not notice the queue was empty, or send you a "wakeup" before you sleep

Yes, indeed, there would have to be some form of synchronization involved. My current message queue implementation is wrapped in mutexes to prevent such a thing from happening.

If I were to devise a scenario where IPC could be done (at least mostly) in userspace, that I would also add a "futex" implementation to userspace to compliment it.

--Jeff

One way you could do it is this:
Threads do not share memory with any other thread or address space automatically. Threads can 'connect' to each other by 'asking' the IPC engine to do so (i.e. thread A makes a syscalls asking to share some memory with thread B, and also can ask for certain properties (i.e. stopping the other side from writing to it, etc)). This solves one of your problems, because one evil process can no longer screw with the shared message ques of any other threads. (thinking about it, this may have been exactly what pype was saying...)

Now for the problem of syncronisation. I can see that the best way of implementing things like locking and waiting is by integrating your IPC with the page fault handler. The kernel could mark shared memory space as read only so as to stop anyone but the thread that is using it writing to it. Also, if a thread wanted to block until a shared memory stream was writen to again, the IPC manger could mark that space a 'not present' in the other threads that used that stream. Then, when a page fault occured as it was written to, the IPC manager could unblock the waiting thread.

Hope this helps,
OScoder