>If the _user_ uses devfs, the _developer_ has to provide it. A halfway
>system is worse than each alternative on its own.
Big fat lie. It falls on the user to use MAKEDEV in conjunction with
devfs if a driver is non-devfs.
>But does when enabled. One more variable to consider on each support call.
So CONFIG_DEVFS=N.
>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.
Yes they have, he was on the linux-usb list. Stop
ignoring people.
>Change MAKEDEV, be my guest.
CHALLENGE: You give me a script that finds the
bus, target, and lun for every SCSI and IDE device
on the system without devfs.
>/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?
You're a dunce. I can't be nice anymore.
>Can't do that, because it is deeply ingrained into the kernel's way of
>handling devices.
Big fat lie.
>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.
BIG fucking fat damn lie.
>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
Again, write me a script that determines the SCSI host,
target, and LUN on your linux box.
>(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.
That's a lot of words to lie just once.
>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.
BIG FAT LIE.
-
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/