On Fri, Nov 19, 2004 at 11:51:55AM -0800, Bill Studenmund wrote:
> On Thu, Nov 18, 2004 at 08:26:27PM -0600, Eric Haszlakiewicz wrote:
> > 	I don't think it would be any messier than writing code to store
> > the information in a file instead of a filesystem.  With the file
> 
> 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. 2)

	Well, it's a little simpler with the data file backed devfs, but you
still have the data file vnode that you have to deal with.  And you still
have the three classes of vnodes, except the modified devfs vnode is a
vnode+extra data instead of vnode+vnode.

> You're still relying on "traditional" node names to identify the device.  
> One of the big advantages I see of a devfs is that we can now use locators
> to identify devices. I mainly see it in terms of disks on a SAN, but using
> locators can make a lot of stuff work quite nicely. Like you can have an
> office/work group machine that different folks hook USB sticks into. We
> remember device permissions and tie them to the S/N of the stick (I admit

	hmm.. so what does a locator look like?  If it's something that isn't
easy to represent as a single line of text I think I can see how having
a central devfs persistance info file would be useful.

> > > I uesd to think some idea using on-disk device nodes would work, but I 
> > > don't anymore. Why shouldn't we just synthesize the whole thing from 
> > > scratch?
> > 	I think you're missing my point.  There _aren't_ any on-disk device
> > nodes.  The only time a device node appears is when it is synthesized
> > by the devfs.  devfs uses the on-disk state to modify how the in-kernel
> > devices appear to userland.  Let's take the rename a device node example:
> 
> No, I got that point. I had that point, and I argued it for years. I now 
> think it isn't a good one. I think it ends up being quite cumbersome.

> Read my reference to "on-disk device node" to mean a node on the disk, 
> either a file or symlink, that contains info for a device node. I did not 
> specifically mean that it has to be a char or block dev node in the 
> underlying fs.

	I'm confused.  I read this as "it's bad to not have on disk device nodes".
Which seems to conflict with the earlier impression I got that you'd
prefer a single database file to hold persistent devfs info.
Are you saying that there should be on-disk "device nodes" that control the
appearance of the actual device node or not?

eric