False. It stays in the source, developers have to take it into account,
device drivers will have to be written both ways (devfs and not), ...
>
> 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/