Re: FreeBSD devfs support on NetBSD 5.0

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Personally I think local permissions and ownership changes, symbolic
> links, and the like need to be supported in a completely transparent
> way, but that's almost trivial to do with a simplified type of
> unified filesystem overlay mount, one which stores only meta-data
> overrides for underlying files (or almost like an extension to the
> umapfs, one which stores the new meta-data).

I'm not so sure.  You need new operations, peculiar to this mapping
layer.  It seems to me this mapping layer would need a way to represent
"node FOO is like underlying node BAR (possibly with changes)", which
is not that hard, except that you need a way to create such a thing
when underlying node BAR has already been moved, in the same way, to
BAR2.

In a traditional /dev, this would be done with "mv BAR BAR2" and then
"mknod FOO ...".  But to work with this kind of devfs, this needs a
mknod-alike which takes an underlying-layer device name rather than
major/minor numbers (which makes it peculiar to this mapping layer).

One of the biggest problems with devfs, it seems to me, is that it
constrains where devices can exist.  If you want a device node outside
/dev, you have to mount a (heavily constrained) devfs there, which
compels dedicating a directory to the device - you can't just plop a
device down in a directory alongside other things.  (I don't want this
often, but when I do, there's usually not much else that will do.)

> Such filesystem layering is already well supported and relatively
> well understood.  With this kind of mechanism there are no
> configuration files whatsoever to mess with (especially not any
> requiring in-kernel parsers or whatever) to store such information,
> or any other non-standard or non-intuitive aspect to it whatsoever.

Disagree.  The mapping layer has to keep its metadata _somewhere_.  Or
do you consider it acceptable to have to recreate it afresh each boot?

> You could still grab all this meta-data from the union FS by simply
> collecting it with standard filesystem management tools, such as
> "pax"

I don't think so, not unless you either (a) extend pax to understand
these nontraditional device special files or (b) use traditional
major/minor device number pairs (in which case what have you actually
gained?).

> Other than that devfs should simply be a live representation as a
> filesystem of the autoconf tree.

Yes, that's the usual idea of devfs...and as far as I can see, you're
handwaving all the hard problems by pushing them off into this magic
mapping layer, without offering any idea how to solve them there.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B