Re: You could do worse than Mach ports

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
: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