> > 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.
Just to note, it apparently no longer does the tarball evil-ness,
instead has a config file that is used to set the permissions on the devices,
of course, this isn't updated by chown/chmod, but I imagine it might be able
to be, but then, that may get kind of ugly... What are your thoughts?
> 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.
devfs, for me at least, is mostly about having a nicer, cleaner /dev
nodes, ones that make more sense. (c1t1d0s0-style, not this /dev/sd[a,b,c]
junk). Either way here, that's policy, not much you can do to avoid that
either. Having the dynamic filesystem is somewhat handy as well, esp when
you start dealing w/ dynamic devices (PCMCIA, USB, etc).
100kb on a 1.4m floppy is a pain, 100kb out of 4m or 8m of memory
doesn't seem as bad. for embedded systems, it may be easier to use one over
the other, but either way you still use the 100kb.
> > > 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.
Hardly. The way this appears to be handled to me is you do the stupid
simple thing, you ask the hardware. The name is based off of the controller
(Which there SHOULD be, but I'm not sure is, some deterministic way of finding
out which would be appropriate, based on the hardware, to come first), the
physical scsi target or ID, the physical LUN, and the partition on the disk
(As detected by the kernel). This makes it MUCH easier to debug problems on a
large system, because you know right off what disk is acting up.
Stephen
-
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/