Jeff Garzik wrote:
Luben Tuikov wrote:
I never contended that userspace should be moved away from HCIL.
Then, by implication, SAS and FC must continue to maintain HCIL<->device
maps.
Yes, but not in the SAS/ FC/ iSCSI/ USB/ SBP-2/... low-level. HCIL does
not exist there. HCIL is only a bonus for the interface to userspace.
Therefore HCIL should be sticked to those devices by the core, somewhere
close to the surface to userspace. The low-level should never care that
arbitrary HCIL tuples should be added for some applications in
userspace. Moreover...
What I contend is that _internally_ SCSI Core start moving
away from HCIL and towards SAM.
...the whole notion that low level provides "hosts", "channels" etc. is
often wrong. usb_storage and sbp2 always had to resort to a one target =
one "host" implementation for several reasons. But there is no "host",
there is only a bunch of targets.
[...]
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.
Yes. And there would be transport classes which do not control hardware
at all but rather push a high-level protocol (iSCSI, USB mass storage,
SBP-2...) over another whole infrastructure which they share with many
unrelated protocols. These SCSI transports are separated from hardware
by several more layers of abstraction, at least two of those layers
being in-kernel programming interfaces.
--
Stefan Richter
-=====-=-=-= =--- ==-==
http://arcgraph.de/sr/
-
: 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
