DragonFly kernel List (threaded) for 2003-07
Re: You could do worse than Mach ports
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:
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
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.