Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 09/28/05 17:00, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>Ideally SATL is just a _data transformation function_ and
>>getting to the ATA device is transport dependent.
> 
> 
> Incorrect.  It needs to issue multiple ATA commands to emulate a single 
> SCSI command, cache some state, and other details.  Not purely data 
> transformation.

Yes, this is right and I'm aware of it.  I really, really,
had some wishful thinking.

> What needs to happen is that SPI-specific stuff in the SCSI core needs 
> to be moved to SPI-specific transport code.
> 
> Then all transports will be at an equal level, and the SCSI core will be 
> fully transport-agnostic.

Yeah, I've been saying this for ages:
Read half way through my message from 2003 here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=104257405408078&w=2

> "time and again" means that we have been specific multiple times. 
> Re-read your emails from James and Christoph :)

So you're saying that they are right and I'm wrong,
and I should listen to them.

Which is _exactly_ what I've been pointing out:
"the community" thinks that only they are the
experts on the planet regarding new technologies,
thus they are right, engineers "outside the community"
are dead wrong and they should listen to what
"the community" says.

Shall I point out a multitude of emails whereby some
"community members" go out on _technology_ public lists
and start a flame war, until they are warned to behave
or be expelled?  Is this what you mean the "they" are
right, and "we" are wrong?

The community calls specs "techno-gibberish"
and think that LUNs can be u64, that REQUEST SENSE
clears ACA, and that HCIL is here for ever, etc.

Excuse me if I simply ignore their "SCSI storage advice".

>>If you understood how different those architectures are,
>>you'd understand what I mean.
> 
> 
> James is wrong here.

Either you meant "Luben" here or you've been banned
forever from "the community" and your patches would never
ever be accepted.

> The "transport class" in reality winds up as a 
> transport lib, in addition to simply exporting attributes.
> 
> There will always be functions that are common to a transport. 
> Christoph calls this "libsas", since software-driven SAS implementations 

Look at the pictures (since its easier) in SAM/SAS/SPC.
It is not a "lib" it is a _layer_ in its own right,
which is completely and fully implemented in the FW
of an MPT-like (IOP in package) solution.

Access to _anything_ transport specific is _FIRMWARE_
specific and doesn't yield to unification as does
a SAS Transport Layer management.

The only unification you get is: "Here is a LLDD giving
you LUs to manage, and oh yeah, here is some FIRMWARE
dependent way to peek at the transport and transport
attributes".

>> I do not _know_ how to consolidate the completely broken
>> "design" set forth by JB and company.
>> 
>>It is _completely_ not to SAM spec.
> 
> Not true.  Just because SCSI core lacks an explicit "execute SCSI 
> command" RPC hook, does not imply that that capability is non-existent.
> 
> Stare at the Scsi_Host_Template some more and you'll see it.

Well, then, how can I reply to this?

I say "1+1=2", you say "Not true.  1+1=3."

Show me the equivalence between the Scsi_Host_Template
and SAM, give me section references as well.

What I meant is that the place and design of JB's transport
attribute "blessing" is completely out of whack for SAM
abiding implementation.

Look at the pictures: the transport layer is _below_
the application client and the application client
is completely unaware of the transport.

Now lets translate (http://www.t10.org/scsi-3.gif) :
    Command set drivers  <-->  sd, st, etc (application client)
                SAM/SPC  <-->  SCSI Core to be
        Transport layer  <-->  SAS (all others implemented in LLDD)
                    SDS  <-->  LLDD + Firmware
           Interconnect  <-->  Firmware + hardware.

It is _this_ SAM architecture which allows you to say,
send SATA commands over SAS links (via STP), and do other
interesting things.

I guarantee you that any _new_ SCSI transport would yield
to a Transport Layer abstraction just as SAS does.

Since, this is what SAM _is_ (all about).

I don't mind James Bottomley entertaining his
"transport attribute" code, as long as he's not shoving
it down my throat (again because of pictures like the one
above).

As I've said before both implementations are _orthogonal_
and can coexist.

>>But an AIC-94xx and BCM8603 _is_ NOT a scsi_host material.  It is just
>>an interface to the interconnect.
> 
> A scsi_host is simply a container.  You're being too literal.

By "too literal" do you mean "following specs too closely",
or do you mean "being realistic without tweaking things".

> Yes.  We need to evolve the SCSI core to separate out SPI-specific 
> pieces, to make it more transport-agnostic.

2003:
http://marc.theaimsgroup.com/?l=linux-scsi&m=104257405408078&w=2

> James and Christoph have been asking you to submit patches for a long 
> time now.

Not patches to fix SCSI Core or to get "struct scsi_domain_device"
into SCSI Core or to get 64 bit LUNs into the kenrel.

They've been asking me for me to abandon the complete
SAS transport layer which I have, which is 1000 years ahead
of theirs and ahead of SCSI Core and to go and work
on LSI's and on "transport attributes".

Sorry, but SAM seems to disagree.

> James, Christoph and the rest of linux-scsi have been saying this over 
> and over again.

They've never said it: why else do you think we do not
have 64 bit LUNS or why else do you think we have HCIL in
SCSI Core.

Instead, what James does is he goes off to implement
"transport attributes" and to submit patches to IDR
after I myself submitted patches to IDR?  Why?  So he can
undermine my patches?  Well, as you can see I completely
removed IDR's usage from aic94xx.  Now "the community" is happy.

> Everybody knows the SCSI core is too SPI-centric, and you have been 
> given a recipe for fixing this.

I "have been given recipe for fixing this"?

Are you all right Jeff?

Yep, the recipe was given to me by people who think that
we should stay with HCIL, who have found purpose for
the "second channel" in HCIL, who think that REQUEST SENSE
clears ACA, who think that 64 bit LUN is just a waste, and
so forth with their antics.

So excuse me if I don't see or recognize the recipe
given to me.  Mind pointing out a link?  This way we
will have a hard coded evidence of what that recipe is.
And we can see the exact steps it outlines.

Thank you,
	Luben


-
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/