lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) )
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.042 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site