:
:Although some of the communication primitives are reminiscent of
:microkernels, and there is the intent of moving some things into
:user space, he wants to avoid having applications pay the performance
:penalty in the common case. L4 is a dramatic improvement over Mach,
:but L4Linux had to be tuned to an incredible degree to get it to the
:96% of native Linux that they quoted. These days with the improvements
:that have been made in Linux 2.4 your looking at 65% of native.
:
:His emphasis is much less on protection boundaries because of the
:cost that one tends to incur from them.
:
: -Kip
Yes, precisely. I feel that protection boundaries are better handled
by the port agent. e.g. this is how a typical message is sent:
SomeMsg blah;
blah.XXX = ... /* ... fill in blah ... */
code = targetPort->mp_SendMsg(targetPort, &blah); /* send the message */
if (code == EASYNC) /* async completion? */
code = waitMsg(&blah); /* yes, wait */
return(code); /* else sync completion */
For user<->user messaging mp_sendMsg() is simply the target port's
message handling function. Ditto for kernel<->kernel messaging.
But for user<->kernel messaging or kernel<->user messaging the
targetPort would be the local representation of the port (not the
actual port), and mp_SendMsg() would broker the message to the actual
port, doing whatever work is required to deal with the protection
boundary.
Theoretically this means we can write device and VFS driveres that can
be compiled up as either user OR kernel modules. They would see the
same API either way and only mp_SendMsg() would change.
That's the idea. It is very similar to how the Amiga's I/O system
(DoIO, SendIO, BeginIO, etc) works. The performance aspects of the
design should be obvious... no queueing unless you really need to,
queueing controlled by target port's agent (could just forward to
actual target port if targetPort is a shim), no queueing the
reply unless necessary, no queueing of the reply if the client is
waiting for it synchronously, easily embeddable port/message structures,
etc.
-Matt