Subject: devfs with shadow status on disk beneath, was Re: devfs, was Re: ptyfs
To: None <>
From: Chapman Flack <>
List: tech-kern
Date: 11/13/2004 12:15:21
der Mouse writes:

> What about "mv /dev/lpt1 /dev/spinner", how does that get represented
> in the on-disk layer?  Presumably a whiteout is created to hide
> /dev/lpt1, but what happens for /dev/spinner?

An interesting question, but one I doubt would be too hard to address; of
various possibilities, the simplest might be a symlink, with appropriate
semantics in the devfs layer; or a device node with a magic value in maj/min
that match something you stash with the whiteout entry ... devfs might hunt
for such things at mount time and reduce them to a suitable internal data
structure, so the on-disk representation doesn't necessarily have to be
something that would support blindingly fast matching by itself.  But see
the next question for a deeper answer.

> # mv /dev/tty00 /dev/foo
> # mv /dev/tty01 /dev/tty00
> # mv /dev/foo /dev/tty01
> how does that get represented?  (Yes, such things have their uses.)

I'll take your word for it ... but that brings up another point I've been
seeing over and over in this thread - we want all of our saved attribute and
device name data to be stable across autoconfig in the face of environment
changes that could affect autoconfig order.  It seems worth making an eensy
weensy point that, as far as I can tell, *there are only two fundamental
ways of doing that.*  You either let the kernel map from locators to your
intended assigned names, as by constraining autoconfig so it knows the locators
of the devices you care about and always gives them the names you want,
or you make locator-based canonical names visible in userland and do your
own mapping to your favorite names there.  There are different ways to go
about either approach, but those are the two columns on the menu.

If you want it done in the kernel, you'll either use config syntax, or a
suitable slight extension of it, to get your constraints built into the
configuration tables, or you'll invent a new file somewhere with a syntax
very similar to config and containing data that can get out of sync with it,
to be read by devfs at mount time or something.

If you want it in userland, it might wind up looking like something I
remember from Solaris, where there's a /devices directory with canonical
names like /mainbus/pci@0/ppb@1:0/pci@1/neo@0:1/audio and /dev has symlinks
into it, or something else where there is some canonical name you can rely
on.  And when there's a canonical name you can rely on, the earlier questions
become nonquestions.