Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 10/21/05 15:39, Jeff Garzik wrote:
> The technical stuff got covered long ago.  Here are the basic basics:
> 
> * aic94xx needs to have the scsi-host-template in the LLDD, to fix 
> improper layering.
> * SAS generic code needs to use SAS transport class, which calls 
> scsi_scan_target(), to avoid code duplication.
> * other stuff I listed in my "analysis" email, including updating libata 
> to support SAS+SATA hardware.

All this bastardizes the code and the layering infrastructure.

If you're saying that there is "improper layering" you must be
smoking something really strong.

I'd suggest you talk to storage engineers with years of storage
experience about the design of the Linux SAS Stack.
I'd suggest you take a look at the USB and SBP code.
I'd suggest you take an overview of all of SAM and see how the protocols
fit together.
I'd suggest you take a look at the hardware design and see how and _where_
it fits and where it does not and _why_.
I'd suggest you take a look at the event management interface
(drivers/scsi/sas/sas_event.c) what it is, how it provides _all_
communication from LLDD to SAS Layer, filled in by the SAS Stack.
I'd suggest you take a look at the Execute Command SCSI RPC and the TMFs,
declared in the struct sas_ha_struct, filled in by the LLDD,
how they provide all communication from the SAS Stack to the LLDD (inteconnect).

I'm even ready to do a presentation in front of people explaining
the design of the Linux SAS Stack, why and how it works.  Specify
time and venue, please.

(I will put something up on the web site -- html and figures
to show the layering, function stubs, event management, etc.)

> This is the stuff that I have been working on (nothing pushed to sas-2.6 
> yet, as it doesn't yet boot locally).

I'm sorry to hear that.  Maybe you shouldn't have to bastardize the code.
Implement SDI and then everyone will be happy.  Look, I've alredy twice
posted code and templates, just grab it and put your name there.

Think about it: there is no reason to mess with the code.  It is
present at the link below, it works and people are using it.  It is also
sound and spec complient.  There are other subsystems which use the exact
same layering (namely USB Storage and SBP) which is consistent with the
SCSI Architecture Model all new protocols abide by.

> If you were willing to do this stuff, _working with others_, then I 
> would be off in happy happy SATA land right now, and you would have been 
> nominated to be the Linux SAS maintainer.

You seem to be traveling a path which I've already traveled.

Jeff, if you want an Adaptec SAS driver which has the host template
_in_ the driver, you can use "adp94xx" submitted earlier this year
by Adaptec to "the community".

"The community" rejected it. Why?  Because "common SAS tasks should
be in a common layer".  Well there you have the Linux SAS Stack and
aic94xx at the link below (my sig), which does separate common SAS
tasks and the interconnect _as per architecture and spec_.  Apparently
this still isn't good enough for "the community".

You see how this going around in circles just never seems to end.

One day one thing, another day the opposite, etc.

> Call it FUD, politics, personal attacks, wanking off to please 
> manglement, whatever.  My goal has always been to (a) help Linux users 
> by getting aic94xx+SAS upstream, and (b) try to help you understand why 
> your code didn't go upstream verbatim, long after others have given up 
> trying to do that.

(a) There are Linux users using "aic94xx+SAS" right now.  They've
downloaded a working Linux code from the link at my signature.

(b) I think it was because Linux says "no to specs" and you say that
"specs are the source code".

> 	Jeff, he of infinite patience

Everyone is very pleased with you.  You will go places.

	Luben
-- 
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/
-
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/