> You still need to stuff around allocating major&minor numbers. Part of
> the motivation for this is to avoid that.
I'm not convinced I understand what you mean. I mean, if you want to be
able to boot non-devs-enabled kernels, you *do* need to have a regular
/dev directory.
And if you're sure you only will run devfs-enabled kernels, why, then
you have the option to just make a dummy /dev directory with the right
names/permissions etc.
I'm not sure my point got across, which was to use the old /dev
directory(ies) as configuration for the devfs, and then in turn use a
devfs mount to "shadow" the /dev directory.
> The semantics of adding entries (what happens if overlayfs is not
> mounted yet and a driver "exposes" (installs) the /dev entries?) are
> sufficiently complicated that you need a special-purpose devfs, IMHO.
The way I pictured it, if you load a module, it will only register its
device in the devfs - any old mknod'ed /dev directory won't see any
difference, and nothing will actually happen to disk. Directories
mounted as none -t devfs would see it (or not, depending on the
configuration of the directory it shadows).
Say I want to have some special purpose directory with a printer
device. I could then, in /my/dev/ do an mknod to get a printer device
file. It would work, as long as the appropriate functionality was
present in the kernel.
Now, mounting none -t devfs on top of /my/dev would show the device file
iff the functionality was present, and no other device files, inheriting
from the original directory.
Would something like that be workable? It seems to me like a workable
solution, but I might be blatantly ignoring lots of low-level issues, I
know.
~kzm
-- If I haven't seen further, it is by standing in the footprints of giants