DragonFly kernel List (threaded) for 2003-07[
Date Prev][
Date Next] [
Thread Prev][
Thread Next] [
Date Index][
Thread Index]
Re: You could do worse than Mach ports
::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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next] [
Date Index][
Thread Index]
