> Be fair:
>
> - it doesn't impact drivers unless the developer chooses to use devfs
If the _user_ uses devfs, the _developer_ has to provide it. A halfway
system is worse than each alternative on its own.
> - it doesn't impact system adminstration unless you enable the feature
But does when enabled. One more variable to consider on each support call.
> - it doesn't break filesystem semantics anymore than /proc already does
> - UNIX devices aren't the best: tradition for tradition's sake is crazy
> Also just because you don't add/remove devices very often doesn't mean you
> are the poster child for all Linux users. I don't have any need for initrd
> but I wouldn't dare argue it should be removed for this reason alone.
I've never said that everybody is like me. I'm careful to talk about my
experience, and what I have seen. As far, nobody at all has stepped forward
telling the grueling story of his machine with hundreds of devices that
change minute by minute, so I'd have to assume that this doesn't exist, or
in any case is so marginal that any impact at all on the kernel used by
millions that don't have any use for the feature is out.
> > Reasons for devfs:
> >
> > - Makes handling hot-plug easier, but marginally so
> > - Unclutters /dev
>
> Be fair:
>
> - gives sensible names to devices (c1t3d0s2 instead of sde)
Change MAKEDEV, be my guest.
> - eliminates scsi ordering problems because of sensible names
/dev/c1t3d0s2 becomes /dev/c2t3d0s2 when you move the controller, and
adding a new disk gets you to /dev/c2t4d0s2. How does this solve the "sdc is
now sdb" problem?
Check mount(8), options -L, -U for a solution to this.
> - completely eliminates major/minor number problems
Can't do that, because it is deeply ingrained into the kernel's way of
handling devices.
> - moves naming complexity INTO USER SPACE (good for usb)
MAKEDEV is user space.
> - user space scripts ran on insertion (just like cardmgr/PCMCIA)
Can be done (sort of) with modules and pre- post- scripts. Not nice.
> - UNIX-like /dev without UNIX-like rw fs (good for embedding on romfs)
ROMFS is designed to be _small_, not full-Unix. I'd guess adding device
nodes to ROMFS won't make it much larger. Surely much less than devfs and
its bloat in all devices by itself.
> - provides a proper namespace (no need for recent rash of /proc/*/dev)
If you can't provide a proper namespace in /dev, then doing it as a fake
filesystem is out anyway.
> Notice that all of these problems can be solved in other ways (for example
> you can solve the sde -> c1t3d0s2 problems using a startup script, similar
> to how Solaris populates /dev) but devfs solves ALL of the problems in one
> fell swoop.
That isn't exactly right. As said above, it does not solve all problems.
Plus the naming problem is still there, it is just shifted from MAKEDEV
(yuck!) to either another configuration file (same yuck!) or the driver
itself (double yuck!), which will have to find out if it is controller 2 or
3 this time just for the sake of naming its devices (triple yuck!). Also,
if you rename your disks that way, they will still be /dev/sdX for
everybody else. The naming issue is _not_ local to your machine only,
unless you prefer to live in a vacuum. Also, if something solves several
problems in one fell swoop _without_ adding strange klugdes and needing
extra machinery, it's an elegant solution (the conception behind Unix is a
fine example). If not, it's just exchanging one mess for another one. My
fear here is that devfs exchanges an acknowledged mess, which we know and
over time learned how to handle in a reasonable way; with a much larger
mess, one with unknown quirks that will have to be worked around. All for
no real gain.
> > Also: It is extra code, has to be maintained and updated, and has to be
> > accounted for in new driver developments. It _will_ add new bugs, even new
> > classes of bugs. This doesn't come for free.
> Well, perhaps all kernel developers should stop coding right now: you have
> equally well argued against all new features and drivers.
Yes, I did. But if the costs involved are smaller than the benefits, go for
it. If not, leave it alone. In this case, as no pressing need has surfaced,
and no clear benefits have been shown, leave it alone.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/