On Sun, 2007-10-14 at 18:45 -0500, Rob Landley wrote:
OK, so could we get back to the original discussion? The question I
think you meant to ask is "does SCSI use the block layer, and if so;
how?"
The answer is yes (just do an ls /sys/block on any scsi machine). The
how is that it bascially uses the block layer as a service library (i.e.
most SCSI services are built on top of those already provided by block).
The email you cited was basically from our one area of confusion: SCSI
and block both provide services to decode the SG_IO ioctl. This is
partly historical; block and SCSI are very much intertwined; so much so
that they both tend to drive each other's development. The programme
over the last few years has been to identify features in SCSI that
should be more generic (and hence moved to block). SG_IO is one of
these, so we end up with the situation where Block provides this as a
service (and sr, st and sd make use of it) while the sg driver still
doesn't use what the block layer provides but rolls its own. I think
the layout of how all this works is illustrated at a reasonably high
level here on slide 15:
http://licensing.steeleye.com/support/papers/ols_2005_slides.pdf
OK. But that's the bit I need you to separate from your inquiry into
how SCSI actually works. You can't go on a research trip if you allow
preconceived notions to spill over into it.
For the record, USB and firewire are SCSI at their core, so they can
never really be separated. SATA (but not SATAPI) is a separate
protocol, so it can theoretically be separated later, and we are
actually working on that. It's only in SCSI because there's a well
defined and standardised way to place it their (called the SAT
layer---SCSI to ATA Translation) and because it's a lot easier since
SCSI has all the features and quite a few of the necessary ones aren't
yet migrated to block.
However, by design choice, we got the SCSI layer in the kernel out of
the business of trying to provide a stable name space, since Richard
Gooch did a brilliant job of demonstrating the insoluability of that
problem. There are many ways to identify a device (UUID being just one
of them). It seems much more desirable to give the users the choice.
You can even have what you seem to want (SATA stably at /dev/sda) simply
by ensuring that you have a modular kernel and that libata always loads
before USB or any other storage device (not that I'd recommend doing
this, because it will fail for a large configuration, but it would work
for you).
That was because your initial inquiry came across as "I'm trying to
document this, and by the way it's rubbish". By all means have an
inquiry and an argument, but saying effectively I don't understand this
but I know it's wrong is a guaranteed way to antagonise everyone who's
worked to try to make all of this as functional as possible. Find out
the facts first then argue from them.
OK, so look at the diagram and the other SCSI documents and come back
for further clarification as you need it.
James
-
