Re: What still uses the block layer?

Am Mon, Oct 15, 2007 at 04:26:04AM -0500 schrieb Rob Landley:
To clarify, I think that merging ide, sata, usb, firewire, and others into a
single device namespace causes each type of device to inherit that
namespace's cumulative ordering issues, which is a bad thing. I have no real
attachment to the underlying scsi or block layers. I've never seriously
worked on either (although I'm trying to understand both).

For example, usb devices are never easy to order. IDE devices (back when they
had their own namespace) were trivial to order back when /dev/hda couldn't
move without use of a screwdriver. USB and IDE devices are very different in
that it's not possible to plug a USB device into an IDE controller (not
without one _heck_ of an adapter) and vice versa. USB devices usually live
outside the computer's case, and IDE devices inside the case. They're not
the same thing.

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.

I have udev here, and it generates several useful symlinks.
/dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part2 will always point
to the second primary partition of the IDE master on the first IDE
channel here, be there as many USB sticks as there may.

(But still I'd like it if it wasn't named "scsi-0:0:0:0", because the
"0:0:0:0" part could change.)

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?

I don't think there was any intent to merge namespaces. It "just happened"
as a byproduct of having sata/pata use the scsi subsystem.

Wilfried
--
Irgendwas ist ja immer...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Loading