I think a close analogy would be that after a partition is mounted you
don't need to know the path to the hard drive, and that is already true
today. when you mount a drive (or assign and IP address to a network
interface) the path to the device not only matters, it's critical.
I also have a 3TB raid I built at home, it uses 3ware cards and a dozen
300G IDE drives. since the 3ware driver is classified as SCSI if a drive
fails all the other drives get renumbered on the next boot and it's
painful to figure out which drive has a problem. I have to reboot and go
into the 3ware BIOS to figure out which drive isn't reporting. This system
also has an adaptec raid card in it and an adaptec regular SCSI card. The
fact that these three cards take different drivers, and so the order of
detection changes the drive numbering is a real pain when I'm installing a
new distro onto it. once I get it installed I compile my own monolithic
kernel and this problem stops becouse the kernel linking order determins
the detection order.
this replaced a 1.2TB raid that I just about filled up, and then stared
having drive failures due to age on. It used 8 160G IDE drives, and when I
had problems with a drive it was easy to see that /dev/hdk was missing
from the set, and I was still able to have a removable drive bay for
/dev/hdc that I could hook my tivo drive into (on a reboot for safety) and
not have things go haywire if I left the bay empty (or switched off) when
I booted.
this may not be hundreds of drives, but it should be enough to show that I
have experianced the pain that some people claim is the reason all of this
must be dynamic with a userspace helper to sort it all out. My take is
that adding the userspace helper and not enumerating things that are easy
to enumerate is making things worse, not better.
but these are seperate SATA buses, while you could run into ordering
issues if you hook multiple devices to one bus, you should be able to have
no ordering issues if you don't have more then one device of a type on any
one bus (you could have a SATA hard drive on the internal PCI controller,
and another one of the Cardbus controller, but if you always order
directly connected devices before cardbus connected devices they will
always show up in the same order)
there are two seperate problems here.
1. how to enumerate devices that have a repeatable, stable address.
2. how to enumerate devices that do not.
nobody is saying that there are no cases of #2 and that there is no need
to address that problem, what I, and I think others are saying is that the
solutions to #2 are not perfect, and while they are a reasonable fit for
that case, they are in many ways inferior to simple enumeration for
devices in catagory #1
the kernel wasn't just built for people who have dozens or hundreds of
devices on busses that make enumeration impossible either, why should
their requirements be the only ones considered?
(by the way, I think the crack about who is paying Rob's salary is a
little below the belt)
so let USB devices use 'best guess' nameing and let other devices use
names based on their fixed addresses/hardware paths.
you could use the suggestion made by Stefan Richter in Message-ID:
<47139F15.7050702@s5r6.in-berlin.de> that lets the driver suggest a name
if the system hasn't choosen to override it. Since distros look for
/dev/sd* it should even be able to work without breaking new installs (the
transition would break existing installs, so it would need to be optional)
David Lang
-
