Re: What still uses the block layer?

[Rob Landley <rob@landley.net>]

On Monday 15 October 2007 12:44:19 am Stefan Richter wrote:
> Rob Landley wrote:
> > I was at least attempting to ask a serious question.
>
> ...
>
> > Actually, I was going through Documentation/block thinking about making a
> > 00-INDEX for it, but my earlier questions of the scsi guys left me with
> > the impression that the block layer is _not_ used by the SCSI layer.
>
> Ah, so it was about your documentation work.

Well, triggered by.  (This documentation stuff makes me poke into corners of 
the kernel I ordinarily otherwise avoid, for various reasons.  I don't 
currently have the luxury of saying "beats me how this bit works, not my 
area".)

> I already forgot the 
> context of your previous inquiries.  Alas the tone of them already did
> some damage, leading to responses like these.

Sorry about that.  My social skills are finite, I tend to exhaust them when I 
do too much at once. :(

The resulting documentation should be very polite and apolitical. :)

> > since
> > every non-embedded modern storage device I'm aware of has been consumed
> > by the SCSI layer (despite none of them actually having a discernably
> > closer relationship to SCSI than ATA did)
>
> The Linux SCSI subsystems don't consume, they provide services; nowadays
> not only for SCSI hardware and SCSI protocols but also for a number of
> subsystems whose tasks are similar enough to SCSI subsystems to make the
> SCSI core and upper SCSI layer useful to them too.

This discussion has clarified for me that my objection isn't the scsi layer 
itself, it's the /dev/sd? namespace combining devices that would otherwise 
be /dev/hda, /dev/nd0, /dev/ub0 (or usb0 or some such), and /dev/sata into a 
single linear namespace that's unreliably ordered. 

> BTW:
> | Now that IDE disks have been rerouted through the scsi layer, SATA goes
> | through the scsi layer, USB goes through the scsi layer, firewire goes
> | through the scsi layer...
>
> As a side note, SBP-2 is a SCSI transport protocol, hence ieee1394/sbp2
> and firewire/fw-sbp2 are Linux SCSI low-level drivers.  Anything else
> would be just wrong and infeasible in this particular case.

My "scsi mid layer" vs "block layer" question was about whether I should read 
up on the block layer if the scsi mid layer didn't use it.  Neil Brown just 
sent me a nice email (which I'll have to reread in the morning when I'm more 
awake) that helps there.

The "ide/sata/usb/firewire->scsi" complaint didn't belong in the same email as 
the original question, it's a line of questioning I put on hold on linux-scsi 
back in August when the thread started getting a bit heated for my tastes.

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.  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?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/