> > Reasons against devfs:
> > - 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...
> 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?
> > - 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.
> > - Impacts system administration,
> by making things easier...
... and others impossible/hard.
> > making device managing a lot less Unixy
> FreeBSD has devfs. Is FreeBSD not Unix?
Never looked into that.
> > - 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. Bloat; stability and security suffer.
> > - What can be done with devfs can be done without it.
> Hot-swapping?
Yep. See HPA's proposal, or the way AIX does this.
> Also, what about kmod/kerneld? We can get by without them...
Yes.
> > But I add/remove devices from my machines perhaps once a
> > month, so that doesn't cut it for me.
> The key point being *for you*. There are people (PCMCIA, USB, Firewire,
> ...) who do add/remove devices frequently.
The _same_ devices all the time. Just like I pop in diskettes, CDs and
Zips. Not that I want /dev/fd0 to appear when I place a diskette in it, and
dissapear when I take it out. And if you don't want something like that,
what is dynamic /dev for?
> > Reasons for devfs:
> > - Makes handling hot-plug easier, but marginally so
> - 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.
> > - Unclutters /dev
> - 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.
> - 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? ;-)
Besides, device naming is a quite local matter; and devfs is being
described as completely compatible with a traditional /dev, so this doesn't
amount to much.
> > Also: It is extra code, has to be maintained and updated, and has to be
> > accounted for in new driver developments.
> This is true for ANYTHING new.
Yes. But you have to get something out of it in exchange, which I just
don't see here at all. Color me blind.
> > It _will_ add new bugs
> 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.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616
- 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/