DragonFly kernel List (threaded) for 2003-07
Re: You could do worse than Mach ports
First, the dragonfly message ports could cheaply act as a proxy to a
more heavyweight messageport where that's needed, so the current design
doesn't exclude Mach message ports or anything else weird and wonderful
you want to layer under them.
Terry Lambert wrote:
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:
QUOTAFS Implement quotas for all FS's
UMSDOSFS Implement UNIX permissions, etc., on top of
FS's which don't support it
I'm not sure why either of these would require doing anything more with
the user data itself than passing it through unchanged, unless you
decided to store this metadata inline with the file data... which is
probably not the optimal design. :) Even if the metadata is stored in
the file you can keep it in a fixed size block and just adjust offsets.
Transformation, yes. You would need to add a more extensive operation in
the middle... but I'm not sure how having the normal path not touching
the user data excludes this.
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
Again, the data fork wouldn't normally be touched by any of this.
> 4) Semantic layering, where explicit semantics are implemented on
top of the underlying FS, without needing to store specific
Again, you're not goin to touch the content of any data pages, so why do
they need to be in your address space?
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).
Even if this is necessary in special cases those can be handled by
making the Send() function for that message port point to the
heavier-weight message call, or have a proxy message port that then
redirects messages to one or the other if there's only one "syscall"
message port per process.
There doesn't have to be... in fact it would make things more flexible
if there was a message port associated with each file descriptor even if
most of the time that pointed back to the system port.