> > Names _are_ policy. So now I have to hack the kernel to
> > rename the mouse?
> oh come on horst.. you know perfectly well the kernel has to set some kind
> of policy.. it's either major/minor's or names. no way round it. Try be
> constructive.
/dev is in the _filesystem_, and can be kept there. Has been there for
ages, in fact. What is in there smells like files, tastes like files, and
behaves like files: ls(1), mv(1), rm(1), chmod(1), chown(1) all work as
they always do with files. This is an important part of the Unix way.
What devfs proposes is to fake all this functionality, kludgeing
permissions into tarfiles that have to be created when shutting down and
reread when booting. It adds daemons and kernel functionality to "unclutter
/dev", something that can be done with plain rm(1). It creates new devices
on the fly, so the unsuspecting user is suddenly able to mount half a dozen
new partitions somewhere on her filesystem.
Don't you see all this is ridiculous? Maintaining /dev is _not_ a minute by
minute activity, just creating entries for new devices is not enough, not
by a _long_ shot. Sure, it can be nice sometimes, but not enough to pay for
any extra cost, IMHO. Instead of a fake filesystem use a real one. It works
well enough for me, and I still haven't seen any real situation were it
would not be enough, and far simpler than doing extra stuff. People saying
that 100Kb on disk for /dev is too much don't count (devfs will cost at
least that much in RAM). "Clutter" isn't a argument either, you _can_ clean
it up easily. If you really want to, there isn't any real need to go in
there most of the time.
> > There is an even thinner layer that does that, called
> > mknod(8)+chmod(1)...
> ie operator intervention, which is going to get more and more awkward as
> devices become more and more dynamic.
The problem with dynamic devices is not exactly "naming", it is "making use
of them". That suddenly there is a /dev/sdx with a dozen partitions doesn't
do me any good, I'll have to mount them somewhere. That is exactly your
much-dreaded "operator intervention" again. And what do we do if I
disconnect /dev/sdx? More operator intervention. Or you'll magically mount
/dev/sdx somewhere when it appears. Like on X:. But then X: is useless as a
file, _unless_ /dev/sdx just happens to be present... and now you add
another /dev/sdy, which yesterday _was_ /dev/sdx. What should we do here?
If you want to get rid of "operator intervention", you'd better start
redesigning the whole operating system idea (and probably computers too)
from scratch. Might be a good idea in itself, but devfs clearly falls quite
short.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/