You could do worse than Mach ports

[Ulrich Hobelmann]

Matthew Dillon wrote:
    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.
Could this be done by dynamic linkage?  So the ELF-symbol mp_SendMsg 
would be translated by the linker, or the in-kernel module loader to the 
right function depending on context.

This makes it easy to unload a module from the kernel und reload it as a 
user process for debugging etc.

Ulrich