> > > - Permanent attributes are kludged on
>
> > True, but it works. It's no more kludged than some other stuff in the
> > kernel (remember umsdos?). Less kludged actually.
>
> If an ugly, evil klutz as umsdos is your standard...
It's not my standard, but another example of an ugly kludge that works and
is useful nevertheless.
> > Also, the current USB device naming system in 2.3.20 is a very ugly kludge
> > that can go away with devfs.
>
> It could go away in other ways to. Why _must_ it be devfs?
Nobody is saying it _must_ be devfs (at least I'm not). Devfs is a
possible solution though, and we have it right now, and it makes a lot of
other things easier, especially for newbies.
Advanced users who for whatever reasons don't like it can just turn it
off.
> > > - Breaks filesystem semantics in several ways, makes it very hard to check
> > > ramifications
>
> > How so? I don't see it breaking anything.
>
> Persistence. Try adding ACLs cleanly.
Cleanly: granted, this is a problem.
Kludgy: possible without any major implications.
> > > - Impacts system administration,
> > by making things easier...
> ... and others impossible/hard.
Such as?
> > > making device managing a lot less Unixy
> > FreeBSD has devfs. Is FreeBSD not Unix?
>
> Never looked into that.
Have a look at FreeBSD 4.0-CURRENT to see an example of a working devfs
that is more widely in use than the Linux patches...
> > > - Impacts _every_ single driver in the kernel, even if it isn't used
>
> > Only at the source level if CONFIG_DEVFS is not set, and the changes
> > needed at source level are so minimal that someone with no previous kernel
> > programming experience could do it in half an hour.
>
> If it is set, it impacts all over.
True.
> Bloat;
That's a matter of opinion. You can consider anything bload. We don't
really "need" kmod, /dev/pts, a.out (anyone still using that?),
chipset-specific IDE support, khttpd, knfsd, isapnp or pcmcia (the latter
two have been implemented without the main kernel supporting them) in the
kernel either - are all of those bloat too?
> stability and security suffer.
How so?
I haven't seen stability problems with devfs even though I'm using it on
Linux and FreeBSD.
Unless you think of someone editing the permissions file (writable by root
only), I don't see security problems either - and once someone can write
to a root-writable file, you're in trouble anyways.
Am I missing something?
> > The key point being *for you*. There are people (PCMCIA, USB, Firewire,
> > ...) who do add/remove devices frequently.
>
> The _same_ devices all the time.
Really? I, for example, use PCMCIA to connect my notebook with a D-Link
DE640 to my home network, or with a Trust EtherLink PCMCIA at office...
With USB hardware becoming more common, we'll see more problems like that
- connecting computers (especially notebooks) to (different) printers
everywhere, and that's just one of the examples.
> Not that I want /dev/fd0 to appear when I place a diskette in it, and
> dissapear when I take it out.
This is different, because /dev/fd0 is the floppy drive, not the diskette.
You still need to access /dev/fd0 if you want to probe if there is a
floppy drive, or if you need to check if there's a diskette in it, and
such.
But you *don't* necessarily want to have /dev/usbprinter109 when the
specified USB printer is not connected.
> > - Makes handling hot-plug possible without ugly kludges
>
> See above. It is quite possible right now (heck, I do it with a Zip drive
> reasonably often). Haven't seen any kludges.
That's possible only because the Zip drive (parallel port, I presume)
always connects at the same place. This is not guaranteed for connecting
to chains of USB hardware.
> > - Easy possibility for userspace tools to know about installed hardware
> > (Just check /dev/sound to see if there is a soundcard and what it can
> > do!)
>
> Check /proc/devices or something like that. It's _much_ easier, actually.
/proc/devices could be extended to give the same functionality, yes.
> > - Compatibility (with FreeBSD and other BSDs that will take up the
> > solution)
>
> "Compatibility with OSes that will [might?] take up the solution" is the
> wrong way around, isn't it? ;-)
FreeBSD has taken up the solution, and experience shows that mostly
anything that gets into one BSD will be ported to the other BSDs.
> Besides, device naming is a quite local matter;
Until you start writing shell scripts that you want to use on your Linux
and FreeBSD boxes without having to modify all the names.
I agree this is not an important issue though.
> > True. But they won't affect you if you say CONFIG_DEVFS=N.
>
> If the CONFIG_DEVFS handling is badly implemented, it can screw up other
> code, even when disabled.
Right. If. It isn't. Read the patch.
LLaP
bero
-
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/