Luben Tuikov wrote:
On 08/26/05 14:48, Jeff Garzik wrote:
No host numbers, no routing information. This is all
transparent to SCSI Core, and NONE of its business.
Routing is an essential part of the SCSI core's duties.
[I'm not a big fan of reading mixed-message emails, but what can you do...]
The SCSI core is the resource manager responsible for routing messages
[CDBs] to/from LLDs based on <scsi-specific device address>. This
includes resolution of kernel-specific identifiers (device major/minor,
etc.) into <s.s.d.a.>. This also includes direct use of
This particular is the task of sd.c. How it does it is
sd.c. job. Not SCSI Core.
No. sd, sr, st, and sg all use the -common- infrastructure to execute
tasks and return results. That common infrastructure is part of the
SCSI core.
The SCSI layer itself is a marraige between
device classes -- sd, sr, st, sg
transport classes -- common per-transport code
drivers -- executes tasks via transport class
glue -- the myriad functions that tie the above 3 together
All transport-specific knowledge that is common across hardware vendors
should be in the transport class. The SCSI core uses the transport
class to perform transport-specific actions.
userspace-provided identifiers as <s.s.d.a.>, such as via SG_IO ioctl.
Ah, yes, I see. So the question is, how do we fit SG_IO ioctl?
SG_IO can be transport/protocol agnostic _if_ SCSI Core gets
the architecture right.
I.e. if I show you a picture of the objects "out there" in the
SCSI domain, you can just point to one and send something to it.
That picture will be painted by the transport layer. SCSI Core
is _completely_ unaware of all this! This is how you can accomodate
SMP and any future protocols that can come your way.
The SCSI core is the common point for exporting bus topology via
transport classes.
Moving away from HCIL requires a lot of thought, including thinking
about userland app breakage -- a big deal in Linux.
I never contended that userspace should be moved away from HCIL.
Then, by implication, SAS and FC must continue to maintain HCIL<->device
maps.
What I contend is that _internally_ SCSI Core start moving
away from HCIL and towards SAM.
SAM is already mostly there. ->queuecommand is already a pretty good
execute_task().
Most easily this would be done by implementing a bunch of
new-way-to-do-it functions. The request_queue wouldn't care,
and old LLDD can use the old interface, and new ones can use
the new interface.
Disagree. Just follow the TODO list Christoph outlined, plus figure out
how to handle SG_IO and /dev/sg sanely.
We don't need yet more
if (new way) {
...
} else {
...
}
code blocks :)
HCIL addressing gunk largely belongs in SPI transport class, along with
scsi_scan_host() [each transport class should build its own topology].
This achieves the result you want to achive: new-way-to-do-it functions
live in the SAS and FC transport classes (with generic code in generic
SCSI layer), old-way-to-do-it HCIL functions live in the SPI transport
class.
Ask yourself where all these HCIL-addressed CDBs come from... each one
of those CDB submittors must be updated from HCIL addressing/routing to
transport-specific.
No, no transport specific -- I repeat again: the whole point is to move
away from "transport specific". _SCSI_Core_can invent an HCIL label for them,
not LLDD as they currently do.
You will never be able to eliminate transport-specific code. That's the
whole point of transport classes: encapsulate common transport code.
Call it a transport library, rather than a class, if "class" gives
people the shivers.
Example: I have access to SAS+SATA host controllers from Adaptec and
Company X. Both are largely software-based, directly controlling the
PHY ports and manually performing all SAS+SATA discovery.
I would expect that adaptec_sas and companyx_sas drivers would share
transport-specific code via the ata_transport and sas_transport classes.
Jeff
-
: 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
