On 08/22/05 00:55, Matt Domsch wrote: > On Sat, Aug 20, 2005 at 12:15:41AM -0400, James.Smart@xxxxxxxxxx wrote: > >>- There are some real challenges in supporting a udev-named boot >> device. For the most part, it's a distro issue, which is becoming >> better. PS: for $10, name a 2.6 distro that uses udev out >> of the box for disk names and its installation. For $10 more, >> can it install/boot from one? > > > I won't get your $10, but RHEL4 has a mechanism to specify "install > onto BIOS disk N", where N is typically 80h (it's an int13 number, > what BIOS typically boots from). EDD in anaconda handles the mapping > of BIOS disk number to /dev/whatever. Hi Matt! How is it going? I wonder, do you think it would advantageous to provide another label to a disk device which includes this mapping? (This is in lieu to the "myriad of labels" notion I've been talking about recently, where vendors (BIOS, Dell, disk manufacturer, transport layer, etc, etc, etc.) provide yet another label. This label is tacked to the LU (most commonly a disk, it is *not* an FS label.)) This way, user space, or whoever, can look up the LU (disk device) by a label, that label or whichever one. > And a few folks at Dell are > working on a udev helper to let udev know this mapping too, and > incorporating the same capability into SLES in the future. > > After install, file system labels have been working great for years. > root=LABEL=/ syntax for example, and you can get as complex as you > like with that label. Yes, that's cool. How about specifying the LU label _and_ the FS label to "root="? root=[<disk label>:]<fs label> <disc label> := WWN, HCIL, Funky name 1, Funky name 2. <fs label> := filesystem specific label. All those labels are tacked onto the LU, and are provided by various layers: transport, LLDD, vendor, manufacturer, etc, etc, etc. Luben - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
