Re: You could do worse than Mach ports

[David Leimbach <leimy2k@xxxxxxx>]

>    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