You could do worse than Mach ports

[Matthew Dillon]

:Matthew Dillon wrote:
:>     For system calls the foreign address space is the user process's
:>     address space.  User data pointers come in three forms:
:> 
:>     (1) They represent a file path
:>     (2) They represent a large block of data (e.g. the buffer in a read())
:>     (3) They represent a small block of data (e.g. gettimeofday()).
:>     (4) They represent the message itself
:
:Question:
:
:What component is responsible for this rewriting?

    Probably the syscall code in the kernel.  The first thing it would do
    is translate the message.  This could impose possible stall points
    taking the syscall if the smaller blocks of data or the message
    page-fault (which is unlike to occur since they were just built by
    userland).  The big blocks of data would not stall since it is only
    figuring out the VM object(s), offsets, and ranges.

:	The wrapper or other user code?
:	Send() to kernel?
:	The receiving system call?
:	Something in between?
:
:Could it be table-driven? If so, then the table could provide a place to 
:  handle versioning...

    All of our syscall entry points are individual procedures and most 
    of them already do things like copyin smaller arguments.  The only
    real work we would wind up doing is converting the large block 
    references to the new UIO scheme (which I'm working on as we speak,
    it's a necessary precursor to the DEV work since DEV will no longer
    have direct access to userspace).

    So, no, making it table driven would take a lot longer to do and
    probably not perform as well.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>