DragonFly kernel List (threaded) for 2003-07
Re: You could do worse than Mach ports
: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.
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.