On Mon, 3 Oct 2005, Luben Tuikov wrote:
>>
>> The SAS transport class supports commonality across all SAS
>> implementations. This includes both MPT and Adaptec 94xx.
>>
>> SAS transport class + libsas supports software implementations of SAS,
>> including transport layer management. This includes Adaptec 94xx but
>> NOT MPT.
>
> You almost get it right, other than the layering infrastructure.
>
> The SAS Transport Layer is a layer in its own right. It is not
> a "libsas".
>
> MPT and open transport a very different, one hides the transport,
> i.e. the transport layer is in firmware; the other exposes it
> and needs a transport layer. See the pictures here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112810649712793&w=2
in this case wouldn't it be trivial to write a 'null transport' driver
that just passed things down to the card to let the firmware deal with it?
(reformatting the data if needed)
having a null driver for a layer for some hardware, and a much more
complex driver for the same layer for other hardware is fairly common in
Linux. I believe ti was Linus that said in an interview that Linux is now
largely designed for an ideal abstracted CPU, with code put in on the
architectures that don't have a feature to simulate that feature in
software.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On 10/03/05 10:26, David Lang wrote:
> in this case wouldn't it be trivial to write a 'null transport' driver
> that just passed things down to the card to let the firmware deal with it?
> (reformatting the data if needed)
Hi David,
I think it is trivial.
Your LLDD would define the host template and register it
with SCSI Core. This way you _bypass_ the Transport Layer.
(This is what you call null driver -- as is traditionally done
in SCSI Core due to the legacy LLDDs (to which MPT caters
for 100% backward software compatibility))
Else if your LLDD is just an inteface to the interconnect:
i.e. it only implements Execute SCSI RPC and TMFs, then
you'd register with the Transport Layer (SBP or USB or SAS)
which will do all Transport related tasks, and then that
Transport Layer (USB, SBP or SAS) would register a scsi host
with SCSI Core.
Luben
> having a null driver for a layer for some hardware, and a much more
> complex driver for the same layer for other hardware is fairly common in
> Linux. I believe ti was Linus that said in an interview that Linux is now
> largely designed for an ideal abstracted CPU, with code put in on the
> architectures that don't have a feature to simulate that feature in
> software.
>
> David Lang
>
On Mon, 3 Oct 2005, Luben Tuikov wrote:
> On 10/03/05 10:26, David Lang wrote:
>> in this case wouldn't it be trivial to write a 'null transport' driver
>> that just passed things down to the card to let the firmware deal with it?
>> (reformatting the data if needed)
>
> Hi David,
>
> I think it is trivial.
>
> Your LLDD would define the host template and register it
> with SCSI Core. This way you _bypass_ the Transport Layer.
> (This is what you call null driver -- as is traditionally done
> in SCSI Core due to the legacy LLDDs (to which MPT caters
> for 100% backward software compatibility))
>
> Else if your LLDD is just an inteface to the interconnect:
> i.e. it only implements Execute SCSI RPC and TMFs, then
> you'd register with the Transport Layer (SBP or USB or SAS)
> which will do all Transport related tasks, and then that
> Transport Layer (USB, SBP or SAS) would register a scsi host
> with SCSI Core.
the advantage of actually having a null transport driver rather then
bypassing the transport layer completely is that you avoid having to make
the SCSI core know about details of the interface to the chips, and
especially about any bugs that crop up and have to be worked around for
different chips.
or worse yet, as the spec of the interface to the hardware changes over
time the SCSI core would have to know about all the different variations
and how to deal with them.
it's much cleaner to evict all that knowledge out of the SCSI core and let
a very lightweight transport driver deal with that instead.
the drawback is that you may end up copying a little bit of data one time
more then you absolutly have to, but that's probably a very small cost for
the flexibility.
think of this as a problem similar to the network card interface, vendors
want to implement TOE while the kernel folks are willing to do TSO, but
not TOE (see the letters being exchange on lwn.net in the letters to the
editor section the last few weeks for a good discussion on those issues)
David Lang