Re: You could do worse than Mach ports

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:First: congradulations on the new project!
:
:I know you said you didn't want to go all the way to Mach ports for
:the messaging, but... you could do a lot worse.
:
:Mach ports each take up only 64 bytes.  In addition, they allow for
:the idea of passing pages ranges and/or entire address spaces between
:participants.  I think this type of thing is going to be critical for
:you to realize your user space VFS design goals, unless you are going
:to copy all your data in and out of the kernel.
:
:BTW: that's 64 bytes on a 64 bit machine, so it's the equivalent of
:8 pointers worth, which is not much, considering.
:
:-- Terry

    Well, I used mach messaging long ago on the NeXT machine.  The basic
    problem with mach messages is that they are 'heavy weight'.  The
    messaging system has far too much knowledge about the information
    being sent, and it presumes fairly expensive memory mapping operations
    which I believe can be avoided.

    I far prefer to convert the I/O subsystem to pass VM Object ranges in the
    iovec instead of user address space ranges.  This provides a way to 
    reference the data without anyone having to map it at all... the DMA
    subsystem for example would be able to work directly from the physical
    pages pulled from the vm_page_t's in the object.  And, more importantly,
    the messaging system would not have to have any deep knowledge of the
    data being passed.  It would also be possible to pass VM Object references
    (or their logical equivalent: a file descriptor) into and out of user
    space and only actually map the ones associated with filesystem meta
    data.  File data would not have to be mapped, making a userspace VFS
    stack potentially almost as efficient as a kernelspace one.

    If you think about it virtually all data references in an I/O operation
    do not actually have to be touched or accessed by intermediate VFS layers.
    Not even UFS needs to touch the file data in a read() or write().  It's
    only the client at one end and the physical block device (via DMA usually)
    at the other that ever needs to touch the file data.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>