Re: You could do worse than Mach ports

[Terry Lambert <tlambert2@xxxxxxxxxxxxxx>]

Peter da Silva wrote:
> 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.

That was also kind of my point, when I pointed out the problem
space mapping potential of at least examining the Mach model: in
order to handle this type of thing, it can't be something you
glue on at the back end, it has to be something you allow for,
up front.  That doesn't mean you implement it up front, and make
everyone carry it around, it just means you don't implement up
front something that would preclude implementing it later.


> >       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.

No, I was specifically referring to the quota and attributes
files, which are stored on the FS itself, and which affect
the directory operations, if you want to hide them, and the
file operations, if you want to protect them from being changed
by anyone other than the stacking layer.  In the quota case,
you have to take a pretty heavy-weight view of what constitutes
memtadata, as well, since you have to deal with file extends
via write, which means you need to peek at the bytecount for
payload, and return value in case of success/failure.

In the UMDDOS case, you have to store things like atime, and
other things that you normally deal with via getattr/setattr
in at least a metadata file per directory, if not a metadata
file per file.

Shifting file contents isn't something I explored with any of
the options, but you could imagine a sparse map for a compressfs
or a 2:1 map for representing text contents in one 8 bit charset
as wchar_t's.


> 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
> >       afterwards.
> 
> 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
> >       additional metadata.
> 
> Again, you're not goin to touch the content of any data pages, so why do
> they need to be in your address space?


The problem in these cases is the same as the general problem,
which is that you are exposing the data contents at two levels
in the namespace (potentially, unless you require mount-on-top,
and modify the NFS exports mechanism pretty significantly, etc.).

The reason that the UFS/FFS implicit stacking works, and most of
the other stacking doesn't, in FreeBSD, historically, is that
each of the FS's involved has a non-intersecting semantic set.

By this, I mean that there are no operations exported by one
that are also exported by the other.  This isn't true for the
FS's I identified in my last posting, because in all of them,
you have to at *least* include NFS, if you plan to interoperate
with legacy systems, so it's not like you can split existing
VOP's out safely, and not have to expect to stack on top of
them having been implemented in some underlying FS.


> > 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.

Maybe.  I'd have to see a writeup of the cache ccoherency model
for an FS exposed in kernel space, implemented in user space,
and stacked on top of an FS implemented in kernel space.

-- Terry