Messages in this thread | | | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) | Date | Sat, 09 Oct 1999 21:42:19 -0400 | From | Horst von Brand <> |
| |
Shawn Leas <SLEAS@videoupdate.com> said: > From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl] > >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.
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/
| |