Matthew Wilcox wrote: > On Mon, Oct 15, 2007 at 04:26:04AM -0500, Rob Landley wrote: >> Combining USB and IDE into the same /dev/sd? namespace makes enumerating the >> IDE devices much harder than in the traditional "/dev/hdb doesn't move >> without a screwdriver" model. The merger creates a new problem for IDE, one >> which didn't exist before: the addition or removal of other unrelated types >> of devices may change this device's location next boot. It may be possible >> to add additional complication to the system to compensate, but what was the >> advantage of merging the namespaces in the first place? > > It's not something anyone particularly set out to do, it's just how > it worked out. It was justified by saying "ok, this goes from a 99% > solution to a 96% solution, but there's 100% solution called uuids". > I don't particularly agree with this line of argumentation, but it did > hold sway.
Low-level networking drivers suggest a default interface name (per interface or as a template like eth%d into which the networking core inserts a lowest spare number). Userspace can rename interfaces, but nevertheless it's nice to have different default kernel names for ethernet, wlan etc.. Could low-level SCSI drivers provide similar name templates which give a hint on the transport involved? It's a bit more difficult as with networking interfaces though because - SCSI devices can have sd, sr, st, osst, ch, sg interfaces, - SCSI device files share a namespace with all other device files. E.g. /dev/sd-ide-b - second IDE HDD, /dev/sd-iscsi-e - fifth iSCSI direct access device, /dev/sr-sata-0 - first SATA CD-ROM, /dev/sr-usb-0 - a USB CD-ROM, /dev/st-fw-0 - a FireWire tape drive, /dev/sda - a device whose transport driver didn't propose a name Of course the really interesting names will still be provided by udev-generated symlinks. -- Stefan Richter -=====-=-=== =-=- -==== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html