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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
