Bill Studenmund wrote:

> I think it would be messier in two ways. 1) you have two file systems
> involved. So you have up to two vnodes involved in everything. And you
> have three classes of vnodes: devfs-only vnodes with no underlying node,
> devfs device nodes with an underlying node, and devfs other-nodes with an
> underlying vnode. While an overlay file system can do that, it's messy.

Point taken, but there are choices in implementation.  One choice is to
scan the persistent/disk entries once at mount time, use the information
in synthesizing the devfs nodes, and thereafter have only one kind of
devfs node that you care about; they would look just the same as if you
had scanned a binary file once at mount time and used that information in
synthesizing the devfs nodes.  The only other place you care about the
persistent/disk entries is all encapsulated within a persistUpdate()
function that you call in devfs after applying a chmod/chown/etc to
your own devfs node.  In the file-based schemes, persistUpdate writes
something into the file instead, or tickles a daemon to do it.  So the
file or the underlay fs are really just two representations for the
persistent data; looking at the code you shouldn't be able to tell which
is being used unless you look inside persistScan and persistUpdate to see
what they do.

> 2)
> You're still relying on "traditional" node names to identify the device.

This point I think is a straw man.  Whether the persistent records are keyed by
node-space names or locator-space names is a design choice--regardless of
whether the records are stored in an underlay fs, a text file, a binary
file, or an old rusty Rolodex.  I agree with you that locator-space naming
is the better choice--again regardless of storage method.  An underlay fs
approach that didn't expose locator names would be broken, but no more broken
than a control-file approach that didn't expose locator names.

Regards,
-Chap