[coyotos-dev] IPC redesign issues, goals, and options

Sam Mason sam at samason.me.uk
Wed Feb 14 04:09:52 CST 2007


On Tue, Feb 13, 2007 at 10:19:57AM -0500, Jonathan S. Shapiro wrote:
> 3. Make the ``message receive from FCRB'' be handled by an explicit
>    receive operation. This lets the application do it when it knows that
>    capability/data registers will be clobbered and can deal with that
>    without requiring any fancy activation context stuff. This implies
>    that activation handling (if it remains at all) is orthogonal to FCRB
>    receipt. There are three sub-options:
> 
>    3A) Process is not notified of message availability. Short message
>        payload will be delivered at next explicit receive operation.
> 
>    3B) Process is notified of message availability by soft-interrupt.
>        Short message payload will be delivered at next explicit
>        receive operation.
> 
>    3C) Process is notified of message availability by soft interrupt
>        as in (3B), but only if it is not currently receiving.

> My inclination is to move to some variant of (3).
> 
> 
> Options for Activations:
> 
> I am inclined to keep the activation mechanism, but detach it entirely
> from the message payload delivery. I am inclined to deliver a
> soft-interrupt on message delivery.

I'm not entirely sure what you mean my "soft-interrupt".  But doesn't
this entail two context switches on message delivery?  The first to
enter the activation handler and the second to actually receive the
message.


As an aside, I'm also interested in the reason for registering message
delivery in a micro-kernel.  It appears to offer two advantages;

 1) Performance, if you're working with registers it's probably going to
 be faster.  You don't need to worry about setting up some shared area
 to put the message in, also things are more immediately available to
 the receiver.

 2) Abstraction, the kernel has more flexibility with respect to how
 it operates internally.  Once you dictate that things must appear in
 specific formats in user land then you're imposing tighter constraints
 on the kernel.  This obviously impacts indirectly (and probably
 importantly) on performance.

I'm guessing the main reason you want to registerise things is for
reasons of abstraction, but I'm not entirely sure.  I think it's got
a lot to do with allowing two processes in synchronous communication
to work efficiently, but not sure how this fits in with the option you
noted above.


  Sam


More information about the coyotos-dev mailing list