Subject: Re: devfs, was Re: ptyfs fully working now...
To: None <tech-kern@NetBSD.org>
From: Chapman Flack <email@example.com>
Date: 11/19/2004 15:40:18
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.
> 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.