Re: FreeBSD devfs support on NetBSD 5.0

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sun, 21 Jun 2009 17:51:12 -0400
"Greg A. Woods" <woods%planix.com@localhost> wrote:

> At Sun, 21 Jun 2009 16:47:28 -0400 (EDT), der Mouse 
> <mouse%Rodents-Montreal.ORG@localhost> wrote:
> Subject: Re: FreeBSD devfs support on NetBSD 5.0
> > 
> > > 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).

Interesting, I like the persistency and transparency level this would
achieve...

A main question possibly is how flexible must a devfs be about device
permissions and visibility control?  This probably depends on the
audience that needs it, and if we want to allow using it for situations
such as chroots.  It's probably also good to evaluate if we eventually
want to use devfs by default or everywhere, possibly deprecating
traditional large device trees and MAKEDEV update.  If the target is
desktop-oriented systems i.e., for use only on a future Gnome desktop
install option, and that the traditional way always remains the
default (and still an option with the desktop), perhaps that I was
overengineering in the text I posted.

In case we want to maintain the total visibility and permissions
control which we have with the legacy system, I don't see an obvious
way on how to totally eliminate the need for at least a basic set of
permissions/visibility rules.  It does seem that an overlay relying
on the lower layer's actual files would be elegant for persistent and
transparent changes using standard tools, but there remain situations
where a new node (which never existed on disk or in metadata) must be
instantiated (i.e. if allowed by visibility rules, at least suddenly
appear to exist via the upper layer).

This new node must then either inherit default permissions or somehow
infer them.  We also currently have such a set of default device
creation rules, although they're now embedded in the static MAKEDEV
script...  If we really need this information for devfs, it would
probably be possible to unify these rules in a way suitable for MAKEDEV
(or at least capable enough to generate MAKEDEV, since it must work
with a minimum userland) and devfs?

This appears to be an aesthetic concern, but should a "downed"
removable device also cause its corresponding entry to become
invisible?  If so, the overlay could indeed also hide it while
retaining the lower layer persistent node (or updated metadata) to
restore visible permissions if instanciating the node again.

If I understand however, if more than one devfs mount is to exist, it
couldn't share the same backing persistent files without introducing
races if they updated them, and this is where the need for
mountpoint-specific persistent metadata arises?

I see a few possibilities here (I've actually also wondered if puffs
would make sense to implement any of the three, other than the need for
a proper kernel to userland device state synchronization device... or
rump might assist for debugging if not):

- Instead of an overlay, a fully new fs which is capable of storing
  metadata on a backing file per mountpoint and doesn't need at
  all an existing device nodes tree (in case we want flexible
  permissions, this needs a rather robust set of permissions/visibility
  rules for defaults as there's no existing files to obtain these
  device-specific defaults from at new node instantiation, and there's
  technically no tree at first mount time but the dynamically
  generated one)

- An overlay system using an existing device nodes tree for reference,
  only mounting them "read-only" but also maintaining a custom metadata
  database per instance (making sure that such a metadata system uses a
  unique per-destination-mountpoint file or equivalent).
  Probably also keeping the metadata up to date with any live changes
  on the underlaying nodes, or ignoring such?  If it uses
  say, /staticdev as a read-only reference, an administrator would have
  traditional control over /staticdev and applications would generally
  operate on /dev, or something similar.  Write operations on /dev
  would only update the metadata.  I think this is the approach you
  propose?  The resulting transparency and persistency would be very
  nice, and /staticdev could be shared among chroots with
  mountpoint-specific changes (mounting before chrooting)

- An overlay system using an existing device nodes tree for reference
  but also propagating any change to the backing tree, not needing any
  extra metadata storage but making sure that no two mounts exist on
  the same source mountpoint (which is also always the destination
  mountpoint, failing with EBUSY or similar error).  Nodes on the
  underlaying fs cannot be changed directly once the devfs is mounted
  over it, but changes are propagated directly by the upper layer.
  If this worked the transparency and persistency would also be
  excellent

> Sure there's chroot() and it's ilk (which I don't normally use), but if
> unlink() is also made to work for the meta-only-unionfs then just mount
> another instance and unlink the stuff you don't want, then "upgrade" the
> devfs and the overlay meta-only-unionfs mounts to read-only (the first
> would prevent new device files from accidentally appearing).

I find chroot(2) is nice and lightweight (we also no longer have
systrace as an alternative in this area), but as long as traditional
file system backed device nodes are supported, they'll fortunately work
fine anyway :)

Thanks,
-- 
Matt