Now, onto your reply...
From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
Subject: Re: devfs again, (was RE: USB device allocation)
>/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.
Hmmm... Maybe because they are files. You know, maybe you dislike the idea
of having something like "files"... Maybe we should go back to addressing
blocks of data by sets of offset pairs or something... For the love of GOD,
Horst, files are a magic on their own. A devfs file is AS MUCH A FILE AS
ANY!!!
>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.
Misinformation! Misinformation! Misinformation! Misinformation!
>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.
So you like it. So do it that way. Don't be an ASSHOLE and say just because
you don't like it that it CANT be in the kernel.
>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?
You can, with userland, just like devfs. You could have it monitor for new
devices, and either mount it somewhere and add it to /etc/fstab, or have
user configurable actions to perform for certain classes of devices!!!!!!!
G-d d-mn-t, why won't you stop complaining simply because you "dislike"
something and come up with valid critiques. Where the hell did you get the
"Dr." title anyway???
>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.
Now you're just fuming.
-Shawn
-
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/