> Big fat lie. It falls on the user to use MAKEDEV in conjunction with
> devfs if a driver is non-devfs.
I.e., it introduces extra complexity, as claimed.
> >But does when enabled. One more variable to consider on each support call.
> So CONFIG_DEVFS=N.
Fine. Each support call starts with: "Please recompile your kernel with
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.
1 person?
> >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.
What for? If you want that, hack the kernel so it works that way. Or mount
by label/UUID.
> >/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.
Please explain how moving a disk from one controller to the other being
renamed from c0... to c1... differs from sdb... now being sdg...
> >Can't do that, because it is deeply ingrained into the kernel's way of
> >handling devices.
> Big fat lie.
Have you looked?
> >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.
I don't need that. If I wanted to name my SCSI devices that way, I'd fix
the kernels understanding of minors. Sure, that way minors run out even
faster.
> >(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.
OK, I'd suggest we make it a rule that whoever just has insults left as
arguments acknowledges that s/he lost the argument.
-- 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/