DragonFly kernel List (threaded) for 2003-07
Re: You could do worse than Mach ports
Matthew Dillon wrote:
> 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.
The NeXTStep implementation was on top of Mach 2 (actually "2.5"
is what people call it, though there was never any such release).
The Mach 3.0 messaging is somewhat cleaner about this.
At the very least, you could do worse than to steal some ideas
about the problem space that you will have to cover with the idea
of messaging (yes, I'm aware of your Amiga and VMS experience ;^)).
I admit that the Mach VM primitives are fairly expensive to deal
with, and I would avoid them too, if I could get away with it. I
don't think the messaging implementation is married to them, though.
> 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.
It wouldn't have to be mapped in the pass-through case, which is
currently handled in FreeBSD by the VOP_GETVOBJ (or whatever),
which I had originally envisioned as VOP_GETFINALVP.
> 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.
I really disagree with this (big surprise 8-)).
The problem with this model is that you can only represent a small
subset of the filesystem types, and almost none of the interesting
For anything that does anything interesting, you are going to have
to map file data as well as metadata pages into the address space
of whoever handles operations on the vp; specifically, here are the
classes of manipulations, with a few examples of each:
1) File folding, where you store metadata in a file on the FS,
and hide it from the upper layer, presenting the data in
the file as metadata to the upper layer.
QUOTAFS Implement quotas for all FS's
UMSDOSFS Implement UNIX permissions, etc., on top of
FS's which don't support it
2) Transformation, where each page of data goes through some
transformation from the lower layer representation to the
upper layer representation, in order to normalize it.
ISOUTF8FS Implement conversion of data from a legacy
(e.g. NFSv2, NFSv3, UFS) FS from an ISO
character set, such as ISO8859-1 8-bit data
into UTF-8 representation for the upper
layer code, which expects all directory data
to be stored as UTF-8
CRYPTFS An FS that implements per file encryption using
a restartable streaming crypto algorithm, that
XOR's the pages with the key data to present
unencrypted data to the upper layer on a file
by file basis, instead of restricting you to a
single, global key per device.
3) Directory folding, where you obtain multiple forks for files and
implicit association of metadata, with the ability to back up
and restore the resulting information, and have it functional
EXATTRFS Implements extended attributes on any underlying
FS by converting the file reference to a directory
reference, and the "data fork" into a reference to
a file in that directory, with the ability to store
an arbitrary number of other files there, as well,
calling them "extended attribute streams" instead.
ACLFS Inplement access control lists; this could be via
an "ACL fork" in EXATTRFS, or via some other means.
VERSIONFS Implements file versioning by way of storing the
versions themselves in the underlying directory
that represents the file. Utilizes POSIX namespace
escapes in order to select specific versions other
than "the most recent".
4) Semantic layering, where explicit semantics are implemented on
top of the underlying FS, without needing to store specific
UMAPFS Same as in Ficus/BSD
TRANSLUCENTFS Same as in Solaris
UNIONFS Same as BSD/MacOS X "-union"/"unionfs"
In all these cases, except UMAPFS, you are manipulating data pages other
than those representing strictly metadata. And those are all basically
a heck of a lot more intersting than just "NULLFS", which is what getting
the backing object buys you (at least when crossing a protection domain,
that is all it buys you).
Probably, whatever you call your message port or how you end up
implementing it, you are going to have to treat it as a unit with
the mapping across protection domains interface, in order to avoid
any races between mapping and then operating on the mapped objects
(given your stated out-of-order execution model).