Messages in this thread |  | | Date | Tue, 15 May 2001 12:36:32 -0700 | From | Jonathan Lundell <> | Subject | Re: LANANA: To Pending Device Number Registrants |
| |
At 11:15 AM -0700 2001-05-15, Linus Torvalds wrote: >The part I absolutely detest is when the information becomes more than >just "information", and is used to enforce a world-view. Anybody who uses >physical location for naming devices (ie you have to know where the hell >the thing is in order to look it up), is so far out to lunch that it's not >even funny. And the sad fact is that this is pretty much how ALL unixes >have historically done things ("Oh, you want to see the disk? Sure. It's >on scsi bus 1, channel 2, ID 3, lun 0, so you just open /dev/s1c3l0 and >you're done! Easy as pie!"). > >Keep it informational. And NEVER EVER make it part of the design.
What about:
1 (network domain). I have two network interfaces that I connect to two different network segments, eth0 & eth1; they're ifconfig'd to the appropriate IP and MAC addresses. I really do need to know physically which (physical) hole to plug my eth0 cable into. (Extension: same situation, but it's a firewall and I've got 12 ports to connect.) (Extension #2: if I add a NIC to the system and reboot, I'd really prefer that the NICs already in use didn't get renumbered.)
2 (disk domain). I have multiple spindles on multiple SCSI adapters. I want to allocate them to more than one RAID0/1/5 set, with the usual considerations of putting mirrors on different adapters, spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI paths to config all this, and I further need real physical locations to identify failed drives that need to be hot-replaced. The mirror members will move around as drives are replaced and hot spares come into play.
Seems like more that merely informational.
(A side observation: PCI or SCSI bus/device/lun/etc paths are not physical locations; you also need external hardware-specific knowledge to be able to talk about real physical locations in a way that does the system operator any good.) -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |