lkml.org 
[lkml]   [1999]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc ation) )
On Thu, 7 Oct 1999, Shawn Leas wrote:

> So, you complain and moan about devfs.... So, I publically challenge you
> to tell me what complexity devfs adds to the kernel if you de-configure
> it when compiling? It turns into NOTHING!!!
>
> Now, onto your reply...

You DO realize that you are lowering the chances of getting devfs
into the mainstream kernel by using this kind of an attitude and treating
others in this fashion, don't you?

> >/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!!!

They aren't files in the sense that they are stored on non-volitile
media. As in, in reality, they go away when you shut the machine down, and
come back when the machine boots up. If you boot off of a floppy an OS that
understands the root system, you won't see those files.

> >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!

/dev can be cleaned up using rm(1). devfs at one point used tarballs
to handle permissions, now it doesn't, it uses a configuration file, which
makes it even more strange and un-filesystem like. I don't use a config file
to specify my permissions on my / partition.

> >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 same could be said about many things that would be bad to have 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!!!!!!!

So, what does devfs add then? If it doesn't add anything, then there
isn't much point in having it.

> 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???

His critiques are quite a bit more valid than yours.

> >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.

It would be rude to say what you're doing.

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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.080 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site