DragonFly BSD
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


From: David Leimbach <leimy2k@xxxxxxx>
Date: Fri, 18 Jul 2003 07:25:18 -0500

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.


I am REALLY intersted in the user->user case... In fact I've had some
ideas that have to do with Mach-like port permissions and exposed regions
of memory based on the MPI-2 One Sided [RDMA] semantics. However I haven't
gotten very far with this idea on paper to even decide if its doable....
I want to expose a region of memory for outside access to a known group of
processes or threads for a certain amount of time at which point that memory
could be thought of as "don't touch" for the duration of the epoch... All
accesses to that memory could be considered "remote" during the epoch using
only "put" and "get" requests which I would be relying on the VM layer to do
the writes and reads to the memory in the exposed buffer... even for the local
process.


Does this sound feasible? Like I said, I haven't gotten very far.... but this
API is present, more or less, on high-speed Infiniband hardware drivers as well
as Myrinet GM where there is hardware to do the DMA accesses needed to prevent
interrupting the CPUs of remote nodes so they can continue crunching data while
messages flow through a cluster. Its quite beautiful and elegant in that context.


In user<->user messaging it would just be a natural extension, I think, of this
idea. However I have not counted on context switches and other things that may
need to occur in a BSD/Unix like kernel that may make this design horrible.



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 pretty dang neat. The only part that would change is the target of
the message.



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.

queueing occurs only in the synchronous case then? I need to see that AmigaOS :).

-Matt






[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]