Messages in this thread | | | Date | Tue, 12 Oct 1999 11:54:09 +0200 (CEST) | From | Bernhard Rosenkraenzer <> | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) |
| |
On Mon, 11 Oct 1999, Horst von Brand wrote:
> > > - 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/
| |