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

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

[Moore, Eric Dean]

On Wednesday, September 28, 2005 5:42 AM, Luben Tuikov wrote:
> > Hi Luben,
> > 
> > OK, Man are you alright?
> > 
> > I've heard of other vendors planning to 
> > provide solutions where sas is implemented
> > in firmware, similar to MPT.  Christophs
> > sas layer is going to work with other 
> > solutions, don't think of it being 
> > MPT centric.
> 
> Where in what I said above do I say that it will _not_
> work with _other_ MPT based drivers?  Nowhere!
> 
> Yes it _will_ work with other MPT-like drivers but
> to cut and paste again from above:
>  * MPT based only,
>  * doesn't follow a spec to save its life,
>  * far inferior in SAS capabilities and SAS representation
>    again, due to the fact that it is MPT based.
> 
> When I say MPT, I do not mean MPT(R), I mean MPT as
> in technology, not as in trademark.
> 
>      Luben
> 

Luben: I guess you didn't get what I meant.

I was referring that there are other
*vendors* (not LSI, e.g MegaRAID) that are 
working on sas solutions with sas firmware 
implementation. One that comes to mind is
Intel SunRise Lake, which is non a MPT based 
solution, that would work with Christophs 
Sas Layer. There maybe others, such as emulex.
Perhaps James S. could comment on that.

Eric

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

[Luben Tuikov]

On 09/28/05 11:15, Moore, Eric Dean wrote:
> Luben: I guess you didn't get what I meant.
> 
> I was referring that there are other
> *vendors* (not LSI, e.g MegaRAID) that are 
> working on sas solutions with sas firmware 
> implementation. One that comes to mind is
> Intel SunRise Lake, which is non a MPT based 
> solution, that would work with Christophs 
> Sas Layer. There maybe others, such as emulex.
> Perhaps James S. could comment on that.

This means that they have an IOP on the same
silicone or on the same packaging.

This means, again that they'd done all transport
specific tasks in the FW (by the IOP).

Again, such solutions do _not_ need the
SAS Transport Layer.

They don't even need the attributes, but
as a "nice to have" feature, you can use
transport attributes.

You, as technical person, should recognize
the different needs and thus the different
solutions between LSI's implementation and
Adaptec's.

I'm surprised you never chimed in in defense
of the _different_ technology.

See, I've mentioned many times that the two
radically different technologies can coexist.
But I've not heard any technical word
from the other guys: you.

	Luben

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

[Matthew Wilcox]

On Tue, Oct 04, 2005 at 11:40:17AM -0400, Luben Tuikov wrote:
> On 10/04/05 11:26, Jeff Garzik wrote:
> > You continue to misunderstand everyone else's opinion.
> 
> Internet mailing lists are one such thing where anyone
> can write anything they want and sound smart.  Like
> the statement above.
> 
> Did you talk to "everyone else"?  Or is this just you,
> James B and Christoph?

It's mine too, but I hadn't seen the need to perpetuate this stupid
thread.

> "should", "will".
> 
> The question is then: Where were you Jeff all this time?

Working on other things?  It's not like scsi core is the only armpit
the kernel has.

> Why did the SAS code had to be posted for SCSI Core to see how many
> things it needs to repair.
> 
> I've been pointing those things out since, oh well, for many years
> now.

But people have been working on improving scsi core for many years.  The
transport classes have a copyright daate of 2003 on them, for example.

> If SCSI Core had seen the necessary over the years changes,
> it wouldn't be in this situation now.

Things take time.  Even standards committees.

> > Nothing is upside down.  Transport details plug into an obvious location 
> > -- the transport class, and associated helper libs (if any).
> 
> USB/SAS/SBP:
> HW -> LLDD -> Transport Layer -> SCSI Core
> 
> MPT:
> HW -> Transport Layer (FW) -> LLDD -> SCSI Core.

That's why we still need each driver to have a scsi host template.  That
way each driver can do what it needs to do.  For MPT, that's mostly 'ask
firmware and present the results to sas'.  For other SAS drivers, that's
probably 'call this function in the SAS trransport class that does
everything you want'.

If you like, you can think of it as working around a bug.  Instead of
doing it in the SAS class, we let the driver fix the layering bug.

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

[Luben Tuikov]

On 10/04/05 11:26, Jeff Garzik wrote:
> You continue to misunderstand everyone else's opinion.

Internet mailing lists are one such thing where anyone
can write anything they want and sound smart.  Like
the statement above.

Did you talk to "everyone else"?  Or is this just you,
James B and Christoph?

How do you know everyone else's opinion?

Maybe because you're telling them what they should think?

> The claim is that the transport class is the method through which a 
> transport layer is plugged into the SCSI stack.  Pluggable transport 

No.  This isn't currently the case.  You're maybe making it now
to be like this, but it is currently not the case.

> classes means that SAS transport layer details go into the SAS transport 
> class (or a helper lib).  SPI (parallel/legacy SCSI) transport layer 
> details should move to the SPI transport class.

"should", "will".

The question is then: Where were you Jeff all this time?

Why did the SAS code had to be posted for SCSI Core to see how many
things it needs to repair.

I've been pointing those things out since, oh well, for many years
now.

> You misunderstood that everybody, but you, has moved on to the "what do 
> we do about this" phase.

If SCSI Core had seen the necessary over the years changes,
it wouldn't be in this situation now.

> Nothing is upside down.  Transport details plug into an obvious location 
> -- the transport class, and associated helper libs (if any).

USB/SAS/SBP:
HW -> LLDD -> Transport Layer -> SCSI Core

MPT:
HW -> Transport Layer (FW) -> LLDD -> SCSI Core.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 10/04/05 10:54, Jeff Garzik wrote:
> 
>>Luben Tuikov wrote:
>>
>>
>>>The reason of all this hoopla is that James B, wants to decree
>>>that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
>>>the exception, while in fact it is the other way around.
>>
>>
>>False.  You continue to misunderstand basic stuff about the SCSI core.
> 
> 
> Let me repeat: LSI/MPT is not the norm and USB/SAS/SBP, i.e. having
> an actual transport layer (handling transport tasks, and error recovery)
> is the norm.
> 
> Don't make stupid bullshit generalizations that I "continue to
> misunderstand basic stuff about the SCSI core".

You continue to misunderstand everyone else's opinion.  No one is 
claiming that LSI/MPT is the norm.

The claim is that the transport class is the method through which a 
transport layer is plugged into the SCSI stack.  Pluggable transport 
classes means that SAS transport layer details go into the SAS transport 
class (or a helper lib).  SPI (parallel/legacy SCSI) transport layer 
details should move to the SPI transport class.


> I've probably misunderstood that LUNs are 32 bit (since SCSI Core
> says so) and that REQUEST SENSE clears ACA?

You misunderstood that everybody, but you, has moved on to the "what do 
we do about this" phase.


> But since the layers are completely upside down one compared
> to the other, it would be quite messy unless you can separate
> the implementations and at one or the other (but not both)
> include a basic emulator.  If there is no basic emulator then
> that part would have to be taken by the LLDD.

Nothing is upside down.  Transport details plug into an obvious location 
-- the transport class, and associated helper libs (if any).

	Jeff

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

[Luben Tuikov]

On 10/04/05 10:54, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>The reason of all this hoopla is that James B, wants to decree
>>that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
>>the exception, while in fact it is the other way around.
> 
> 
> False.  You continue to misunderstand basic stuff about the SCSI core.

Let me repeat: LSI/MPT is not the norm and USB/SAS/SBP, i.e. having
an actual transport layer (handling transport tasks, and error recovery)
is the norm.

Don't make stupid bullshit generalizations that I "continue to
misunderstand basic stuff about the SCSI core".

I've probably misunderstood that LUNs are 32 bit (since SCSI Core
says so) and that REQUEST SENSE clears ACA?

I remember answering your questions on task set aborting several
years ago on linux-scsi.

> We are trying to support all these crazy configurations... at once :)

Oh, I'm well aware of what you're trying to do.

But since the layers are completely upside down one compared
to the other, it would be quite messy unless you can separate
the implementations and at one or the other (but not both)
include a basic emulator.  If there is no basic emulator then
that part would have to be taken by the LLDD.

It would be messy.

	Luben

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

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1941 bytes --]



On Tue, 4 Oct 2005, Tomasz K³oczko wrote:
>
> On Mon, 3 Oct 2005, Linus Torvalds wrote:
> [..]
> > This is especially common in the "cheap" market. For example, for SCSI,
> > most of the violations tend to be USB storage - which is supposed to act
> > largely like SCSI, but in reality really doesn't. It locks up if you
> > try to access sectors that aren't there, etc.
> 
> Yes .. of course .. but please don't tap some words (without this kind
> comment) which sounds like rules [1]. *Especialy if* talk is about *one*
> specified piece of hardware.

What "one" piece of hardware? There's a hell of a lot more broken USB 
devices out there (and no, it's not "one" type either) than there will 
probably _ever_ be SAS devices.

And the thing is, from a kernel _maintenance_ standpoint, the broken 
hardware is the one that is expensive. Maybe only 0.1% of all hardware 
ends up having some bugs - but that doesn't matter. It may look like a 
"small" percentage to you, but it ends up being a _huge_ burden on 
developers to try to figure out what is going on, often _exactly_ because 
it's a small percentage, and the developers don't have it.

So the argument that "most hardware conforms to spec" is not a valid 
argument. Not if it's 51%, and not if it's 99.9%. Because the cost is in 
the ones that don't.

And that is why I'm trying to educate people that specs are purely paper. 
Often much less valuable than a roll of TP. 

Because what matters is not the spec, but real life. For example, in the 
SCSI layer we've ended up being much more successful with the approach of 
trying to use the same discovery sequence as Windows - because unlike the 
spec, that's REAL LIFE, and that's the case that actually works.

The same way software inevitably has bugs in areas that haven't been 
tested, hardware has bugs in areas that haven't been tested. It has 
nothing to do with specs, and no, specs don't make people test it.

			Linus

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

[Luben Tuikov]

On 10/04/05 02:51, Andre Hedrick wrote:
> 
> Not everyone has to be a "storage engineer", but a "storage engineer" must
> be able to explain to any OS developer/engineer the scope of the transport
> and work within the OS or explain why a change is required.

Can you not have a storage engineer who is also a kernel engineer?

> This process is moving like rush hours in the SF-Bay area.

Standing still,
	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> The reason of all this hoopla is that James B, wants to decree
> that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
> the exception, while in fact it is the other way around.

False.  You continue to misunderstand basic stuff about the SCSI core.

We are trying to support all these crazy configurations... at once :)

	Jeff

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

[Luben Tuikov]

On 10/03/05 18:56, Linus Torvalds wrote:
> So when the SAS people say that the SCSI layer should conform to their 
> needs, next time they should remember that it _also_ needs to conform to 
> the needs of things like USB storage. Which has totally different goals, 
> implementation issues, and bugs. 

It does, Linus, it does.

SAS/USB/SBP all implement pretty close to SAM architecture
whereby the transport layer (SAS/USB/SBP) sits between
SCSI Core (SAM to be) and the interconnect (USB bus, SAS link,
Infiniband, IEEE1394, TCP/IP, FC, etc).

The reason of all this hoopla is that James B, wants to decree
that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
the exception, while in fact it is the other way around.

This is because 10 years ago, all there was was Parallel SCSI,
and all LLDD implemented Parallel SCSI and above them was SCSI Core.
So in effect there was no need for Parallel SCSI Transport _layer_
between an SPI LLDD and SCSI Core.

What you see in my SAS Code is what you see in USB Storage (sans EH)
and what you see in SBP.  It is the same architecture: layered.

	Luben

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1544 bytes --]

On Mon, 3 Oct 2005, Linus Torvalds wrote:
[..]
> This is especially common in the "cheap" market. For example, for SCSI,
> most of the violations tend to be USB storage - which is supposed to act
> largely like SCSI, but in reality really doesn't. It locks up if you
> try to access sectors that aren't there, etc.

Yes .. of course .. but please don't tap some words (without this kind 
comment) which sounds like rules [1]. *Especialy if* talk is about *one* 
specified piece of hardware. Moving discuss from one point to full 
population many people takes as plain trolling. Luben looks like SAS 
specialist and if you drive discuss outside SAS area this must be 
confusing for him .. and not only for him. And also .. SAS controlers 
this is not '"cheap" market'.

[1] look at comments at /. and osnews: 
http://linux.slashdot.org/article.pl?sid=05/10/02/218233&tid=8&tid=106 
http://osnews.com/comment.php?news_id=12074
look how many people without proper knowledge level assumes: Linus is 
authoritet -> Linus says "spec is close to useless" (without looking on 
context) -> .. probaly spec is realy useless. Of course it is blind 
repeatig but case like this may ruine many thing aroud Linux .. and 
forgive me: you must be aware all this.

Thank You, sorry and regards

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Andre Hedrick]

On Mon, 3 Oct 2005, Luben Tuikov wrote:

> On 10/01/05 19:55, Alan Cox wrote:
> > On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
> > 
> >>that makes me wonder... why and how does T10 control linux abi's ??
> > 
> > 
> > Indirectly the standards do define APIs at the very least. A good
> > example is taskfile. ACPI methods (which we don't yet use) allow get/set
> > mode, get features on the motherboard ATA controller if you don't know
> > how to drive it. The objects they work in are taskfiles. No taskfiles,
> > no ACPI.
> 
> Yes, that's true.

Luben,

Here was your entry point to state SCSI uses "taskfiles" in the packet
transport.

> Even more is true.  Standards and specs define the
> _layering infrastructure_ which if implemented, 
> allows for layer intersection.
> 
> For example, if one needs to insert a SATL later just because
> the underlaying transport was found able to transport it,
> since the layering is well defined and _so_ implemented, it wouldn't
> be hard to interface antother well defined layer in.
> 
> If, OTOH, things are conglomerated into a blob, just because
> the kernel engineers (not (storage) engineers per se) found _no_ current
> use of the layering infrastructure and separating the layers
> was found do add  "more maintenance", then this will turn around
> sooner or later to bite back.

Not everyone has to be a "storage engineer", but a "storage engineer" must
be able to explain to any OS developer/engineer the scope of the transport
and work within the OS or explain why a change is required.

A lot of both has happened so ... to quote Elmo:

"ARE WE THERE YETTTTTTTTTTTTTTTTTTTT!"

This process is moving like rush hours in the SF-Bay area.

Cheers,

Andre

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

[Andre Hedrick]

On Mon, 3 Oct 2005, Ryan Anderson wrote:

> On Mon, 2005-10-03 at 23:26 +0200, Tomasz K³oczko wrote:
> > If (cytation from Linus) "a 'spec' is close to useless" ..
> > Q: why the hell in kernel tree is included Documentation/ subdirectory ?
> > Is it raly content of this directory is "close to useless" or maybe it not
> > contains some specyfications ? :>
> 
> Let me rephrase what Linus said, to help remove the misreading that
> seems so common today.  I think a fair rewording would be, "A spec is a
> guideline.  When it fails to match reality, continuing to follow it is a
> tremendous mistake."
> 
> Additionally, I think the overall LKML feeling on hardware specs and the
> corresponding software abstractions to deal with it can be summarized
> something like this:
> 
> When the spec provides a software design that doesn't fit into the
> overall structure of the Linux kernel, the spec should be treated as a
> suggestion for a software design.  The *interface* that the spec
> documents should be followed, where it moves out of the overall
> structure, but internally, a design that fits into the Linux kernel is
> more important than following a spec that doesn't fit.

Please lets design against the transport or FSM of the storage transport
and never see data again.  NCITS specs generally (used loosely) define the
boundary conditions for stable operations.  One of jewels of linux in the
past which (hopefully was fixed, was 1.2.X-2.5.X thingy) was buffer_head
walking and release to satisfy transfer of data-blocks of a spindle
against the data-blocks of the kernel.  Spindle must win or one can not
insure data integrity, thus the advent of BIO's from BH.

Linux changed to conform to data integrity issues.

Somedays, Linux's API's or designs are OTS (Over The Shoulder).

You get crap all over your back, if you reach OTS to finish your washroom
business.  It is functional but ends up stinky and messy.

This thread is getting longer and I just added to piles ...

Sigh

Andre

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

[Al Viro]

On Mon, Oct 03, 2005 at 03:56:50PM -0700, Linus Torvalds wrote:
> For example, Al Viro pointed out privately that the C preprocessor spec 
> actually matches what a C preprocessor is supposed to do, and that it was 
> easy to generate code from the spec. The reason? The code existed first, 
> the spec was written from that. Writing it back into software "just 
> works", because the spec really _was_ software to begin with, just 
> re-written as a spec.

Not quite, AFAIK.  Existing code was a fscking mess of subtly incompatible
implementations; the thing that had helped was simple - the people who
would have to implement the damn thing had a lot of presense in the
committee.  So it boiled down to
	* observation: attempt to describe it as text transformation leads
to horrors; it really acts on token stream; give up treating it like a text
filter.
	* after figuring out what it should do to sequences of tokens they
ended up with a reasonably simple algorithm that matched the existing
behaviour sans the nasty corner cases everyone handled differently.
	* _that_ had been turned into spec.

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

[Linus Torvalds]

On Mon, 3 Oct 2005, Ryan Anderson wrote:
> 
> Let me rephrase what Linus said, to help remove the misreading that
> seems so common today.  I think a fair rewording would be, "A spec is a
> guideline.  When it fails to match reality, continuing to follow it is a
> tremendous mistake."

Yes (and that _should_ be obvious, but seldom is). But even stronger than 
that.

Even in the case where a spec follows reality, the organization of the 
spec very seldom has anything to do with organization of code.

A lot of people seem to think that spec abstractions should be translated 
into code abstraction. Not so. It often makes no sense to do so at all.

There are exceptions. I suspect that pretty much all of them are specs 
that _used_ to be code (ie they are documentation of real 
implementations).

For example, Al Viro pointed out privately that the C preprocessor spec 
actually matches what a C preprocessor is supposed to do, and that it was 
easy to generate code from the spec. The reason? The code existed first, 
the spec was written from that. Writing it back into software "just 
works", because the spec really _was_ software to begin with, just 
re-written as a spec.

But when it comes to hardware, almost all specs are written from the 
standpoint of the hardware, not the standpoint of the software driving it. 
The spec might even tell you accurately what the hardware does (hey, 
miracles happen!), but that doesn't mean that you should organize your 
software around it.

And the undeniable fact is, that once a spec gets big and complex enough, 
it won't be exhaustively tested. For example, we've seen time and time 
again that the hardware testing has been totally not based on any spec, 
but on just testing against (usually just one, and usually Windows) one 
single implementation of the "other side".

So for example, you'll have a general spec that says that the hardware 
reacts in certain ways, but the only case that has been _tested_ is the 
particular ways that Windows uses. Which is why we have hardware that 
locks up when given commands in the wrong order - where "wrong" is not 
defined by the spec, but by what Windows just happens to do.

This is especially common in the "cheap" market. For example, for SCSI, 
most of the violations tend to be USB storage - which is supposed to act 
largely like SCSI, but in reality really doesn't. It locks up if you 
try to access sectors that aren't there, etc.

And this is where the spec people come in. They think that the "spec" is 
right, and the reality is wrong. So they blame the broken hardware. Which 
is "true" to some degree - there's a lot of broken hardware out there. But 
it's _pointless_. Broken hardware is not an excuse - it's just a fact of 
life. It's not acceptable to say "but the spec says.." 

And yes, the real problem with people ignoring reality are often in the 
high end. The high end tends to be the place where vendors are used to 
saying "we don't use broken hardware". The high end is where people say 
"if it doesn't conform to spec, we don't care: it's broken". In short, the 
high end is where people are the most likely to just ignore the realities 
_outside_ the high end. They'll point to the spec, and say "do it like 
this". Without ever caring that doing it like that simply may not _work_ 
on a lot of setups.

So when the SAS people say that the SCSI layer should conform to their 
needs, next time they should remember that it _also_ needs to conform to 
the needs of things like USB storage. Which has totally different goals, 
implementation issues, and bugs. 

		Linus

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

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On Mon, 2005-10-03 at 23:26 +0200, Tomasz Kłoczko wrote:
> If (cytation from Linus) "a 'spec' is close to useless" ..
> Q: why the hell in kernel tree is included Documentation/ subdirectory ?
> Is it raly content of this directory is "close to useless" or maybe it not
> contains some specyfications ? :>

Let me rephrase what Linus said, to help remove the misreading that
seems so common today.  I think a fair rewording would be, "A spec is a
guideline.  When it fails to match reality, continuing to follow it is a
tremendous mistake."

Additionally, I think the overall LKML feeling on hardware specs and the
corresponding software abstractions to deal with it can be summarized
something like this:

When the spec provides a software design that doesn't fit into the
overall structure of the Linux kernel, the spec should be treated as a
suggestion for a software design.  The *interface* that the spec
documents should be followed, where it moves out of the overall
structure, but internally, a design that fits into the Linux kernel is
more important than following a spec that doesn't fit.

-- 
Ryan Anderson
AutoWeb Communications, Inc.
email: ryan@autoweb.net


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2586 bytes --]

On Mon, 3 Oct 2005, Luben Tuikov wrote:

> On 10/03/05 12:35, Andrew Patterson wrote:
>> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>> They give a means of possible synchronization between beneviolent
>>> users, but not a mandatory lock on the shared resource.
>>>
>>
>>
>> Nor do they protect against external events, such as disk
>> insertion/removals, and someone kicking a cable.
>
> As has _always_ been the case in UNIX:  Provide capability,
> not policy.
>
> The more things are off loaded to userspace the better.
>
> Look at it this way: the deadbolt on your house door does
> not _eliminate_ the possibility of someone cleaning out
> your house, even if you have a security system and/or
> a guard dog.

But using fs like "presentation" layer have some additional "possibilities"
for race conditions because between open() and flock() some other process
can try open the same file. Also this semantics does not provide locking
tree or subtree of files (do I mention procfs and sysfs do not support
locking ? :)
Next is time/cpu concumption because operate on fs like structures
requires open() -> (flock() ->) read()/write() -> close() .. three or more 
context swiching. This is main reason why simple ps takes so many time on
Linux.

Something like simple MIB/OID like semantics for read, write, lock single 
OID or subtree could be very good to mandatory locking for operate on
atributes sets and probably will take less memory than sysfs.

<mode=cynic>
But I know this is like fantasy because seems no one want work on
stabilize kernel API. Even more .. Documentation/stable_api_nonsense.txt
included in *stable* line documents real kernel strategy .. it is 
*pure folclor* (because from this is possible suck something like: "we are
using specyfication: 'we are hate use specyfications'").
If (cytation from Linus) "a 'spec' is close to useless" ..
Q: why the hell in kernel tree is included Documentation/ subdirectory ?
Is it raly content of this directory is "close to useless" or maybe it not
contains some specyfications ? :>
If it is true maybe better will be remove this ? ;->
Maybe after removing Documentation/ with stable_api_nonsense.txt some 
people will can grant permission to start thinking on prepare
specyfication for kernel API usable in longer chunk of time (?)
</mode>

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Jeff Garzik]

Mike Christie wrote:
> For FC there is code like the fc_rport stuff which exports a sysfs 
> interface but also does a lot more like probing and queue blocking.

> And the iSCSI class does do a lot more now too. This just has not been 
> updated. It handles the userspace to kernel communication, session and 
> connection sysfs interface setup,

Great.  Exactly.


> Structures like the fc_rport and iscsi_session are managed by the 
> transport classes so scsi-ml never knows about them (except for that 
> scanning bug). And it is possible to share them between HW and software 
> or partial software solutions. I do agree for some iscsi sitautions 
> having a layer over the eh or command exection where the transport 
> really is more of a layer like your design would be nice (I am not 
> refferring to the code duplication though becuase iSCSI would like some 
> of yrou fixes :), but at the same time there are places where code can 
> be shared between a interface that hides the lower level details and one 
> that implements them in software. Maybe it is not this way for SAS though.

Adaptec's SAS stuff implements the standard high level SCSI model as an 
API, which is a pretty decent direction for SCSI long term:  provides a 
transport-independent execute-scsi-command high level hook (along with 
the other task management functions), and hides the transport details 
for the most part.

That's fine, and works for iSCSI as well.

I just disagree that we need to have two concurrent APIs for SCSI, 
completely separate from each other, and mildly duplicating each other's 
code.

The current SCSI code will morph in the proper direction given time and 
love.  Segregating generic [SPI | FC | SAS | iSCSI | ATA | RAID | ...] 
transport layer code into their own modules -- the transport classes and 
associated libs -- will point out the sore spots where scsi-ml needs 
changes.  This approach also implies we improve the existing scsi-ml 
where needed, rather than the proposed "if legacy, let it bitrot" approach.

	Jeff

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

[Mike Christie]

Luben Tuikov wrote:
> On 10/03/05 12:48, Jeff Garzik wrote:
> 
>>No, transport class is its name.  Think about a standard object-oriented 
> 
> 
> Not according to Kconfig:
> 
> menu "SCSI Transport Attributes"
> 	depends on SCSI
> 
> config SCSI_SPI_ATTRS
> 	tristate "Parallel SCSI (SPI) Transport Attributes"
> 	depends on SCSI
> 	help
> 	  If you wish to export transport-specific information about
> 	  each attached SCSI device to sysfs, say Y.  Otherwise, say N.
> 
> config SCSI_FC_ATTRS
> 	tristate "FiberChannel Transport Attributes"
> 	depends on SCSI
> 	help
> 	  If you wish to export transport-specific information about
> 	  each attached FiberChannel device to sysfs, say Y.
> 	  Otherwise, say N.
> 

For FC there is code like the fc_rport stuff which exports a sysfs 
interface but also does a lot more like probing and queue blocking.

> config SCSI_ISCSI_ATTRS
> 	tristate "iSCSI Transport Attributes"
> 	depends on SCSI
> 	help
> 	  If you wish to export transport-specific information about
> 	  each attached iSCSI device to sysfs, say Y.
> 	  Otherwise, say N.

And the iSCSI class does do a lot more now too. This just has not been 
updated. It handles the userspace to kernel communication, session and 
connection sysfs interface setup, and there were some patches that added 
the ability to tell scsi-ml to stop queueing commands to a iscsi driver.

Structures like the fc_rport and iscsi_session are managed by the 
transport classes so scsi-ml never knows about them (except for that 
scanning bug). And it is possible to share them between HW and software 
or partial software solutions. I do agree for some iscsi sitautions 
having a layer over the eh or command exection where the transport 
really is more of a layer like your design would be nice (I am not 
refferring to the code duplication though becuase iSCSI would like some 
of yrou fixes :), but at the same time there are places where code can 
be shared between a interface that hides the lower level details and one 
that implements them in software. Maybe it is not this way for SAS though.

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

[Marcin Dalecki]

On 2005-10-03, at 18:39, Luben Tuikov wrote:

> On 10/03/05 12:35, Andrew Patterson wrote:
>
>> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>
>>> They give a means of possible synchronization between beneviolent
>>> users, but not a mandatory lock on the shared resource.
>>
>> Nor do they protect against external events, such as disk
>> insertion/removals, and someone kicking a cable.
>
> As has _always_ been the case in UNIX:  Provide capability,
> not policy.

This is at least arguable and not applicable, since we are talking  
about Linux and not UNIX here. UNIX is just fine using IOCTL or  
SYSCTL instead of a crude pseudo file system for this kind of things.

> The more things are off loaded to userspace the better.

That is not the question at hand and an invalid statement per se.  
It's not a design goal in itself to have everything in user space.  
However you admitt indirectly that the problem in question is valid  
and that it exists on the design level of the interface at hand and  
that it's an inherent error in this interface, since you don't know a  
solution to it.

> Look at it this way: the deadbolt on your house door does
> not _eliminate_ the possibility of someone cleaning out
> your house, even if you have a security system and/or
> a guard dog.

Problems which can be solved by proper solutions easly and without  
cost should be solved and not talked away to justify someones idee  
fixe about interface desing.

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

[Mike Christie]

Luben Tuikov wrote:
> On 09/30/05 19:57, Jeff Garzik wrote:
> 
>>Luben Tuikov wrote:
>>
>>
>>>MPT-based drivers + James Bottomley's "transport attributes"
>>
>>
>>You continue to fail to see that a transport class is more than just 
>>transport attributes.
>>
>>You continue to fail to see that working on transport class support IS a 
>>transport layer, that includes management.
>>
>>Is you don't understand this fundamental stuff, how can we expect you to 
>>get it right?
> 
> 
>>From what I see, because of its *layering* position
> JB's "transport attributes" cannot satisfy open transport.
> 
> The reason is that MPT-based drivers indeed do need host template
> in the LLDD.
> 
> Open Transport (SBP/USB/SAS) do not, since the chip is only
> an interface to the transport.
> 
> The host template is implemented by a transport layer,
> say USB Storage or the SAS Transport Layer.
> 

I think I can understand some of Luben's reasons for the layering. We 
are facing similar problems with software iscsi and hw iscsi. For 
software iscsi it would be nice to consolodate some of the common 
software iscsi code into a layer or lib. Following Luben's path for 
example our queuecommand would be:

scsi-ml -> scsi_host_template->queuecommand -> iscsi transport common 
queuecommand (do things like check session state, that we are not in 
session level recovery, scsi to iscsi pdu prep like setting the data 
direction, and other iSCSI PDU prep) -> iscsi_transport module -> 
iscsi_transport->queuepdu (you can probably reccomend a better name) -> 
tcp, sctp, iwarp, or some iSCSI HW that exposes a iSCSI interface rather 
than SCSI (note that qla4xxx would use its own 
scsi_host_template->queuecommand since it does not expose enough iSCSI 
internals for it to be useful to plug in here).

However, HW iscsi cards and software/partial-software iscsi solutions 
can share code for things like session and connection creation where we 
would have transport class lib functions: 
iscsi_add_session/iscsi_remove_session which both the HW iscsi cards 
like qla4xxx and software/partial-software iscsi drivers could use to 
setup things like a common sysfs representation. 
iscsi_add_session/iscsi_remove_session would work similar to the 
fc_rport code where the midlayer doesn't really know they exist (this is 
similar to our session and connection code today but it is bound to the 
scsi host which prevents qla4xxx from using it).

Is the direction we are going where iscsi would have to put the "iscsi 
transport common queuecommand" code into something similar to libata? Or 
  is it that Luben's transport layer code is performing something 
different than software/partial-software iscsi?

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

[Luben Tuikov]

On 10/03/05 12:48, Jeff Garzik wrote:
> No, transport class is its name.  Think about a standard object-oriented 

Not according to Kconfig:

menu "SCSI Transport Attributes"
	depends on SCSI

config SCSI_SPI_ATTRS
	tristate "Parallel SCSI (SPI) Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached SCSI device to sysfs, say Y.  Otherwise, say N.

config SCSI_FC_ATTRS
	tristate "FiberChannel Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached FiberChannel device to sysfs, say Y.
	  Otherwise, say N.

config SCSI_ISCSI_ATTRS
	tristate "iSCSI Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached iSCSI device to sysfs, say Y.
	  Otherwise, say N.

config SCSI_SAS_ATTRS
	tristate "SAS Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached SAS device to sysfs, say Y.

endmenu

> paradigm.  Each transport has unique characteristics.  The proper place 
> to export these and manage these characteristics is the transport layer, 
> as SAM agrees.

But:

>  The manifestation of the transport layer is the 
> transport class.

Bzzzt!  Wrong.

This is where you and James Bottomley make the wrong assesment.

Having the SCSI host template in the LLDD tells everyone immeditealy
that you have it all wrong as far as anything SAM/SPC is concerned.

Look at any transport spec, how little SCSI Host template is there.

You need to understand that declaring the host template in the
LLDD is, and has always been, the _exception_, not the rule.
The reason is legacy Parallel SCSI.

It is MPT based drivers who are the exception, not the rule,
and JB's "transport attributes" makes it the rule, and a
transport layer (what you call libsas), the exception.

It is wrong for a host template to "branch out" to a
transport layer as you're doing it now.  Think about it.
The layering infrastructure is upside down.

> You have to look beyond the current code, to see this.

Eh, well, not that you put it like this, I expect that
you'll completely pull out the implementation from my code
and put it in the "transport attributes" and call it your own.

I don't want to look beyond the current code, I'm discussing
things now, as they are.  How many times is JB going to change
the "transport attributes" just because FC needed one more thing
or because of, as often has been recently seen, "brown paper bag"
fix?

> An implementation of a transport class, in conjunction with helper 
> functions common to all transports (SCSI core), combines to form the 
> transport layer for a specific transport.

Should:

The transport layer sits below SCSI Core and above the LLDD.
SCSI Core is completely unaware of the transport layer.
The LLDD communicates with the transport layer via
the event interface (as shown in the SAS Transport layer)
and the transport layer communicates with the LLDD via
the Execute Command SCSI RPC and TMF.  All as outlined here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629423714248&w=2

>>b) It sits across SCSI Core, i.e. on the same level.
>>c) It was never intended to add management.
> 
> 
> SCSI core is nothing but a set of helper functions and support code that 
> enable the transport class and LLDD to implement the transport layer.

Again you fail to see that the LLDD should _not_ implement
the host template as has been traditionally done.
The reason with this is that simply the LLDD has nothing to do
with the host template.  Unless you're dealing with MPT-based
LLDD which implement everything in FW and export LUs to
SCSI Core (which is fine too, as long as they do not dictate
how SCSI Core should work).

Notice that for MPT-based solution, SCSI Core wouldn't even
do LU discovery (unless you can turn that off via FW dependent
ways).

>>d) Its inteface to SCSI Core is badly defined and an "invention",
>>   (and very poor at that).
> 
> Strongly disagree.  This invention is defined by -needs-, as is other 
> code in Linux.  If we have new needs, we change the code.

You defence of your friends architecture is duly noted.
But if, as has been pointed out, you take a look at the
evolvement of this "invention" you'll see how it was and still
is _meandering_ in the technological maze to find its place.

All the while a transport layer like USB/SPB/SAS and maybe
iSCSI just sits "right".  Think about it.

>>The reason for d) is that
>>2) does _not_ follow _any_ spec or standard.
> 
> 
> That's fine, since its an internal kernel API.

Now, lets shove it down the throat of eveybody.

You forgot to say something about
1) it tries to unify different _transports_.
I don't expect a blurb on that, btw.


	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 10/03/05 11:57, Jeff Garzik wrote:
> 
>>>From what I see, because of its *layering* position
>>
>>>JB's "transport attributes" cannot satisfy open transport.
>>
>>
>>Repeating verbatim the above quote:  a transport class is more than just 
>>transport attributes.
> 
> 
> a) "Transport Attributes" _is_ its name,

No, transport class is its name.  Think about a standard object-oriented 
paradigm.  Each transport has unique characteristics.  The proper place 
to export these and manage these characteristics is the transport layer, 
as SAM agrees.  The manifestation of the transport layer is the 
transport class.

You have to look beyond the current code, to see this.

An implementation of a transport class, in conjunction with helper 
functions common to all transports (SCSI core), combines to form the 
transport layer for a specific transport.


> b) It sits across SCSI Core, i.e. on the same level.
> c) It was never intended to add management.

SCSI core is nothing but a set of helper functions and support code that 
enable the transport class and LLDD to implement the transport layer.


> d) Its inteface to SCSI Core is badly defined and an "invention",
>    (and very poor at that).

Strongly disagree.  This invention is defined by -needs-, as is other 
code in Linux.  If we have new needs, we change the code.


> The reason for d) is that
> 2) does _not_ follow _any_ spec or standard.

That's fine, since its an internal kernel API.

	Jeff

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

[Luben Tuikov]

On 10/03/05 12:35, Andrew Patterson wrote:
> On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
>>They give a means of possible synchronization between beneviolent  
>>users, but not a mandatory lock on the shared resource.
>>
> 
> 
> Nor do they protect against external events, such as disk
> insertion/removals, and someone kicking a cable.

As has _always_ been the case in UNIX:  Provide capability,
not policy.

The more things are off loaded to userspace the better.

Look at it this way: the deadbolt on your house door does
not _eliminate_ the possibility of someone cleaning out
your house, even if you have a security system and/or
a guard dog.

Same thing here.
	Luben

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

[Andrew Patterson]

On Mon, 2005-10-03 at 18:29 +0200, Marcin Dalecki wrote:
> On 2005-10-03, at 15:54, Luben Tuikov wrote:
> 
> > On 09/30/05 19:42, Marcin Dalecki wrote:
> >
> >> On 2005-10-01, at 00:01, Luben Tuikov wrote:
> >>
> >>
> >>> Why should synchronization between Process A and Process B
> >>> reading storage attributes take place in the kernel?
> >>>
> >>> They can synchronize in user space.
> >>>
> >>
> >>
> >> In a mandatory and transparent way? How?
> >
> > Futex, userspace mutex, etc.  All through a user
> > space library interface.
> 
> They give a means of possible synchronization between beneviolent  
> users, but not a mandatory lock on the shared resource.
> 

Nor do they protect against external events, such as disk
insertion/removals, and someone kicking a cable.

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

[Marcin Dalecki]

On 2005-10-03, at 15:54, Luben Tuikov wrote:

> On 09/30/05 19:42, Marcin Dalecki wrote:
>
>> On 2005-10-01, at 00:01, Luben Tuikov wrote:
>>
>>
>>> Why should synchronization between Process A and Process B
>>> reading storage attributes take place in the kernel?
>>>
>>> They can synchronize in user space.
>>>
>>
>>
>> In a mandatory and transparent way? How?
>
> Futex, userspace mutex, etc.  All through a user
> space library interface.

They give a means of possible synchronization between beneviolent  
users, but not a mandatory lock on the shared resource.

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

[Jeff Garzik]

Luben Tuikov wrote:
> As opposed to those vendors saying: We _really_ need 64 bit LUNS
> and it would be really nice to get rid of HCIL, etc, etc.

Everybody agrees with this 100%

Note that James submitted a sdev_printk() patch in the past few days, 
which assists in removing HCIL from the SCSI core.


> IMO, 64 bit LUNs and no HCIL is more important than "transport
> attributes" and should've _preceded_ them.

Agreed.  But that's a lot of work, and I doubt people want to delay SAS 
further to wait for complete HCIL elimination.


> The fact that you're trying to umbrella them together, doesn't
> make it _technologically_ correct.

It's muddled together, yes.  That doesn't make it any less correct. 
It's just not a clean, immediate separation.  Its a separation that 
takes time.

	Jeff

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

[Luben Tuikov]

On 10/03/05 11:57, Jeff Garzik wrote:
>>From what I see, because of its *layering* position
>>JB's "transport attributes" cannot satisfy open transport.
> 
> 
> Repeating verbatim the above quote:  a transport class is more than just 
> transport attributes.

a) "Transport Attributes" _is_ its name,
b) It sits across SCSI Core, i.e. on the same level.
c) It was never intended to add management.
d) Its inteface to SCSI Core is badly defined and an "invention",
   (and very poor at that).

The reason for d) is that
1) it tries to unify different _transports_,
2) does _not_ follow _any_ spec or standard.

Look at this, while you repeat verbaitm a single
quote, I give you technical arguments, then you just
repeat a single quote verbatim... Sad.

> Every chip is ultimately an interface to the transport, regardless of 
> whether the transport layer is largely managed by software (aic94xx) or 
> firmware (MPT).  SCSI host template can work just fine with open 
> transport hardware.

Maybe the picures and the write up here will help:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112810649712793&w=2

	Luben

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

[Luben Tuikov]

On 10/01/05 19:55, Alan Cox wrote:
> On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
> 
>>that makes me wonder... why and how does T10 control linux abi's ??
> 
> 
> Indirectly the standards do define APIs at the very least. A good
> example is taskfile. ACPI methods (which we don't yet use) allow get/set
> mode, get features on the motherboard ATA controller if you don't know
> how to drive it. The objects they work in are taskfiles. No taskfiles,
> no ACPI.

Yes, that's true.

Even more is true.  Standards and specs define the
_layering infrastructure_ which if implemented, 
allows for layer intersection.

For example, if one needs to insert a SATL later just because
the underlaying transport was found able to transport it,
since the layering is well defined and _so_ implemented, it wouldn't
be hard to interface antother well defined layer in.

If, OTOH, things are conglomerated into a blob, just because
the kernel engineers (not (storage) engineers per se) found _no_ current
use of the layering infrastructure and separating the layers
was found do add  "more maintenance", then this will turn around
sooner or later to bite back.

After all, things are what they are.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/30/05 20:33, Jeff Garzik wrote:
>>This is a misrepresentation.  -We- understand the stuff you have posted.
>>
>>But you continue to demonstrate that you simply do not understand the 
>>existing SCSI core code.
>>
>>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".

Different open transport hardware will expose the underlying network at 
different levels.

Hardware A might provide direct access to SSP and IDENTIFY/CONNECT frame 
handling, while Hardware B may handle that internally, while still 
providing full SMP access for the transport layer to discovery topology 
and build its routing table.

We cannot assume that all open transport hardware will function the 
same, hence the better approach is a library of helpers that function in 
concert with LLDD to form a transport layer.


> MPT and open transport a very different, one hides the transport,
> i.e. the transport layer is in firmware; the other exposes it

For the 1001th time, we know all this.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/30/05 19:57, Jeff Garzik wrote:
>>Luben Tuikov wrote:
>>>MPT-based drivers + James Bottomley's "transport attributes"

>>You continue to fail to see that a transport class is more than just 
>>transport attributes.
>>
>>You continue to fail to see that working on transport class support IS a 
>>transport layer, that includes management.
>>
>>Is you don't understand this fundamental stuff, how can we expect you to 
>>get it right?
> 
> 
>>From what I see, because of its *layering* position
> JB's "transport attributes" cannot satisfy open transport.

Repeating verbatim the above quote:  a transport class is more than just 
transport attributes.


> The reason is that MPT-based drivers indeed do need host template
> in the LLDD.

> Open Transport (SBP/USB/SAS) do not, since the chip is only
> an interface to the transport.

> The host template is implemented by a transport layer,
> say USB Storage or the SAS Transport Layer.

Every chip is ultimately an interface to the transport, regardless of 
whether the transport layer is largely managed by software (aic94xx) or 
firmware (MPT).  SCSI host template can work just fine with open 
transport hardware.

	Jeff

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

[Luben Tuikov]

On 09/30/05 20:38, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>I'm sure you'll do whatever humanly possible to show
>>that _your_ idea can be applied: you can do this now:
>>just use a big if () { ... } else { ... } statement and
>>you're done.
> 
> 
> This is not how we do things in Linux.  You're doubling the maintenance 
> burden.

No necessarily.  See below.

> If you really want to do this, at least don't fill up drivers/scsi/ with 
> an additional, completely unrelated codepath.

How do you say it is unrelated?

Is USB storage unrelated? (other than the fact that it doesn't live
in drivers/scsi/)

> There is commonality between aic94xx and MPT/LSI stuff.  aic94xx SAS 
> transport layer is a superset of MPT/LSI SAS transport:  it clearly 
> needs far more management code.

And MPT/LSI SAS does not need this managament as this layer
is completely implemented in FW and not exposed (and for a reason).

> We understand this.  The part you don't understand is that we want to 
> emphasize the commonality, rather than let aic94xx and MPT/LSI go in 
> completely different directions.

But this was LSI's decision, remember?  We did work together,
until LSI and Dell decided that they'd rather let Christoph do it.
(Since who cares about the technological merit of the code when it
will be accepted into the kernel?)

Now you want to integrate the two?  Apparently LSI and Dell haven't
made up their mind.

As I said: Vendors are completely playing to the tune of a couple
of people at linux-scsi, for this reason we haven't seen _any_
SCSI or Storage _innovation_ in SCSI Core.

As opposed to those vendors saying: We _really_ need 64 bit LUNS
and it would be really nice to get rid of HCIL, etc, etc.

If all vendors pushed for that and were not afraid to speak
up (because they have drivers to write and patches to submit
and want acceptance), then SCSI Core would be a better place.

IMO, 64 bit LUNs and no HCIL is more important than "transport
attributes" and should've _preceded_ them.

The fact that you're trying to umbrella them together, doesn't
make it _technologically_ correct.

Remember, a person's fall starts when they're surrounded by "Yes" men.

> Read it again:  aic94xx/BCMxxx is a superset of functionality, not 
> completely different.

One implements all transport related tasks in FW and exposes only LUs
to the LLDD, the other implements only the interface to the transport
in the chip (the interconnect), and the rest is handed to upper layers.

If you sit down with a clean sheet of _paper and a pencil_ and try
to draw out the layering infrastructure for both and how they
interface with SCSI Core, you'll see that with MPT, things are
_upside_ down compared to USB/SBP/SAS.  Now trying to reconcile both,
while possible, would be extremely _ugly_, unless say, you can fake out
event formation in an MPT based LLDD, but then again, you'd need to
resolve the host template thing...

It would just be extremely ugly and not as flowing and straightforward
as the current code is.

	Luben

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

[Luben Tuikov]

On 10/01/05 00:58, Willy Tarreau wrote:
> On Fri, Sep 30, 2005 at 07:54:08PM -0400, Jeff Garzik wrote:
> 
>>Greg Freemyer wrote:
>>
>>>Luben has more than once called for adding a small number of
>>>additional calls to the existing SCSI core.  These calls would
>>>implement the new (reduced) functionallity.  The old calls would
>>>continue to support the full SPI functionallity.  No existing  LLDD
>>>would need modification.
>>
>>IOW, what Luben wants is:
>>
>>	if (Luben)
>>		do this
>>	else
>>		do current stuff
>>
>>If this is the case, why bother touching drivers/scsi/* at all?
> 
> 
> that's the reason why I proposed that this moved to drivers/sas/* or
> somewhere else so that there is no maintaining conflict.

Yes, it has been moved already there.
http://linux.adaptec.com/sas/

	Luben

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

[Luben Tuikov]

On 09/30/05 20:33, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>But none of the ideas: 64 bit LUN, HCIL removal, etc.,
>>were accepted with "submit a patch".
> 
> 
> I concede this may have been the response in the past.  Its not, now.
> 
> 
> 
> 
>>>So you're saying fixing the current SCSI subsystem once *now* costs  
>>>more than applying all *future* SCSI fixes to _two_ SCSI subsystems,  
>>>handling bug reports for _two_ SCSI subsystems, etc.
>>
>>
>>I'm saying that the current "old" one is already obsolete,
>>when all you have is a SAS chip on your mainboard.
>>
>>All you need is a small, tiny, fast, slim SCSI Core.
> 
> 
> Then don't use it at all.  Write a block driver, if you really feel we 
> need two SCSI cores.
> 
> 
> 
>>Politics: "Nah, whatever you say, specs are *crap* and we'll
>>do it our way.  We are not interested in your way, even if it
>>were better.  Oh, and BTW, REQUEST SENSE clears ACA and LUN
>>is a u64."
> 
> 
> This is a misrepresentation.  -We- understand the stuff you have posted.
> 
> But you continue to demonstrate that you simply do not understand the 
> existing SCSI core code.
> 
> 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

	Luben

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

[Luben Tuikov]

On 09/30/05 19:57, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>MPT-based drivers + James Bottomley's "transport attributes"
> 
> 
> You continue to fail to see that a transport class is more than just 
> transport attributes.
> 
> You continue to fail to see that working on transport class support IS a 
> transport layer, that includes management.
> 
> Is you don't understand this fundamental stuff, how can we expect you to 
> get it right?

>From what I see, because of its *layering* position
JB's "transport attributes" cannot satisfy open transport.

The reason is that MPT-based drivers indeed do need host template
in the LLDD.

Open Transport (SBP/USB/SAS) do not, since the chip is only
an interface to the transport.

The host template is implemented by a transport layer,
say USB Storage or the SAS Transport Layer.

This allows you to do great things, like layer
intersection.

	Luben

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

[Luben Tuikov]

On 09/30/05 19:54, Jeff Garzik wrote:
> Greg Freemyer wrote:
> 
>>Luben has more than once called for adding a small number of
>>additional calls to the existing SCSI core.  These calls would
>>implement the new (reduced) functionallity.  The old calls would
>>continue to support the full SPI functionallity.  No existing  LLDD
>>would need modification.
> 
> 
> IOW, what Luben wants is:
> 
> 	if (Luben)
> 		do this
> 	else
> 		do current stuff
> 
> If this is the case, why bother touching drivers/scsi/* at all?

In order to have a new better, faster, slimmer SCSI Core.

	Luben

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

[Luben Tuikov]

On 09/30/05 19:42, Marcin Dalecki wrote:
> On 2005-10-01, at 00:01, Luben Tuikov wrote:
> 
>>Why should synchronization between Process A and Process B
>>reading storage attributes take place in the kernel?
>>
>>They can synchronize in user space.
> 
> 
> In a mandatory and transparent way? How?

Futex, userspace mutex, etc.  All through a user
space library interface.

	Luben

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

[Alan Cox]

On Gwe, 2005-09-30 at 19:53 +0200, Arjan van de Ven wrote:
> that makes me wonder... why and how does T10 control linux abi's ??

Indirectly the standards do define APIs at the very least. A good
example is taskfile. ACPI methods (which we don't yet use) allow get/set
mode, get features on the motherboard ATA controller if you don't know
how to drive it. The objects they work in are taskfiles. No taskfiles,
no ACPI.

Alan

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

[Greg KH]

On Fri, Sep 30, 2005 at 02:22:34PM -0600, Matthew Wilcox wrote:
> There's precedent for binary data in sysfs -- pci config space is one.

binary data in sysfs is for stuff that is just a "pass through" for the
kernel.  Copying the pci config space, in raw form from the device to
userspace is one such example.  Firmware blobs is another one.

Binary data in sysfs is _not_ for exporting kernel structures or other
data that the kernel "understands" and manipulates.

Hope this helps,

greg k-h

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

[Willy Tarreau]

On Fri, Sep 30, 2005 at 07:54:08PM -0400, Jeff Garzik wrote:
> Greg Freemyer wrote:
> >Luben has more than once called for adding a small number of
> >additional calls to the existing SCSI core.  These calls would
> >implement the new (reduced) functionallity.  The old calls would
> >continue to support the full SPI functionallity.  No existing  LLDD
> >would need modification.
> 
> IOW, what Luben wants is:
> 
> 	if (Luben)
> 		do this
> 	else
> 		do current stuff
> 
> If this is the case, why bother touching drivers/scsi/* at all?

that's the reason why I proposed that this moved to drivers/sas/* or
somewhere else so that there is no maintaining conflict.

Regards,
Willy

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

[Jeff Garzik]

Luben Tuikov wrote:
> I'm sure you'll do whatever humanly possible to show
> that _your_ idea can be applied: you can do this now:
> just use a big if () { ... } else { ... } statement and
> you're done.

This is not how we do things in Linux.  You're doubling the maintenance 
burden.

If you really want to do this, at least don't fill up drivers/scsi/ with 
an additional, completely unrelated codepath.


> Furthermore I do not see the reasons to umbrella both
> "aic94xx and LSI cards" when they are _completely different_
> in architecture: MPT and open transport (ala USB Storage and SBP).

There is commonality between aic94xx and MPT/LSI stuff.  aic94xx SAS 
transport layer is a superset of MPT/LSI SAS transport:  it clearly 
needs far more management code.

We understand this.  The part you don't understand is that we want to 
emphasize the commonality, rather than let aic94xx and MPT/LSI go in 
completely different directions.

Read it again:  aic94xx/BCMxxx is a superset of functionality, not 
completely different.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> But none of the ideas: 64 bit LUN, HCIL removal, etc.,
> were accepted with "submit a patch".

I concede this may have been the response in the past.  Its not, now.



>>So you're saying fixing the current SCSI subsystem once *now* costs  
>>more than applying all *future* SCSI fixes to _two_ SCSI subsystems,  
>>handling bug reports for _two_ SCSI subsystems, etc.
> 
> 
> I'm saying that the current "old" one is already obsolete,
> when all you have is a SAS chip on your mainboard.
> 
> All you need is a small, tiny, fast, slim SCSI Core.

Then don't use it at all.  Write a block driver, if you really feel we 
need two SCSI cores.


> Politics: "Nah, whatever you say, specs are *crap* and we'll
> do it our way.  We are not interested in your way, even if it
> were better.  Oh, and BTW, REQUEST SENSE clears ACA and LUN
> is a u64."

This is a misrepresentation.  -We- understand the stuff you have posted.

But you continue to demonstrate that you simply do not understand the 
existing SCSI core code.

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.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> But you can write a user space library which uses sysfs or whatever
> _that_ OS uses to represent an SDI spec-ed out picture.
> 
> So a user space program would call (uniformly across all OSs)
> a libsdi library which will use whatever OS dependent way there is
> to get the information (be it sysfs or ioctl).

Agreed completely :)

	Jeff

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

[Jeff Garzik]

Andrew Patterson wrote:
> SDI is supposed to be a cross-platform spec, so mandating sysfs would
> not work.  I suggested to the author to use a library like HPAAPI (used
> by Fibre channel), so you could hide OS implementation details.  I am in
> fact working on such a beasty (http://libsdi.berlios.de).  He thinks
> that library solutions tend to not work, because the library version is
> never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> he does have a valid point.

Any kernel interface lib should be like libc or libalsa:  it hides the 
kernel details, however nasty they may be, shielding userspace and apps 
from various changes over time.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> MPT-based drivers + James Bottomley's "transport attributes"

You continue to fail to see that a transport class is more than just 
transport attributes.

You continue to fail to see that working on transport class support IS a 
transport layer, that includes management.

Is you don't understand this fundamental stuff, how can we expect you to 
get it right?

	Jeff

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

[Jeff Garzik]

Greg Freemyer wrote:
> Luben has more than once called for adding a small number of
> additional calls to the existing SCSI core.  These calls would
> implement the new (reduced) functionallity.  The old calls would
> continue to support the full SPI functionallity.  No existing  LLDD
> would need modification.

IOW, what Luben wants is:

	if (Luben)
		do this
	else
		do current stuff

If this is the case, why bother touching drivers/scsi/* at all?

Regards,

	Jeff

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

[Marcin Dalecki]

On 2005-10-01, at 00:01, Luben Tuikov wrote:
> Why should synchronization between Process A and Process B
> reading storage attributes take place in the kernel?
>
> They can synchronize in user space.

In a mandatory and transparent way? How?

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

[Luben Tuikov]

On 09/30/05 18:04, Andre Hedrick wrote:
> 
> No true, many of us could careless about credit list.

I wasn't talking about you.  They know who they are.

> Sometimes teaching others is a better way to bring them around to your
> view point while learning about their goals.  Since everyone/most agree
> your T10 knowledge is strong, others have pointed out you are savy enough
> to work around problems over fixing them in general.  Blah blah ...

Thank you Andre.

> Just show everyone why it can not work the "Linux Way" and defend the
> points logically.  Should the defense of it not be possible, then the
> point is lost.

I think I have.  All the references to T10, all the pictures
to the email you replied to which you deleted, all the words.

> SPECs become crap when organizations like STA with T10 make joining and
> voting on the technology under NCITS $10,000.00 annual membership.  This
> is old boys club rules, otherwise I would have joined and terrorized T10
> like I did to T13.  Exclusion breeds distrust.

Well, the T10.org reflector is open to everyone.

Of course voting-membership is expensive.  And it should be so.
They don't want every "Joe" (no offence to Joe or to LKML or LSML
participants) to participate.

If you are a voting member then you really have a reason, you really
know what you're talking about and voting for and you really are
serious. It means that you or your company care.
It also becoms quickly enough obvious if you know your stuff
after a meeting or two.

	Luben

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

[Luben Tuikov]

On 09/30/05 18:10, Greg Freemyer wrote:
> 
> Luben has more than once called for adding a small number of
> additional calls to the existing SCSI core.  These calls would
> implement the new (reduced) functionallity.  The old calls would
> continue to support the full SPI functionallity.  No existing  LLDD
> would need modification.
> 
> Then, over time, more radical restructuring could be done that pulls
> SPI out of SCSI core.
> 
> I believe this proposal is what he was talking about, not the brand
> new simplified SCSI core that has been discussed recently in this
> thread.

See?  There _are_ smart people out there.

	Luben

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

[Luben Tuikov]

On 09/30/05 17:31, Kyle Moffett wrote:
> Jeff Garzik et. al. seem to think that they are necessary, and I  

I've been contending this since before Jeff started work on
libata.  But none of the ideas: 64 bit LUN, HCIL removal, etc.,
were accepted with "submit a patch".

> So you're saying fixing the current SCSI subsystem once *now* costs  
> more than applying all *future* SCSI fixes to _two_ SCSI subsystems,  
> handling bug reports for _two_ SCSI subsystems, etc.

I'm saying that the current "old" one is already obsolete,
when all you have is a SAS chip on your mainboard.

All you need is a small, tiny, fast, slim SCSI Core.

>>>s/Politics.*//g;  I hate politics.  Keep it off this list.
>>
>>Me too, but we are idealists.  Politics is an integral part of life.
> 
> 
> Politics are not an integral part of productive technical  
> discussions, though.  If you discuss technical topics and provide  
> realistic technical descriptions, examples, reasons, code, etc, then  
> politics tends not to matter in the discussion, and we're all happier  
> people.

Yes, please re-read this thread, and open and read all the
references I've included to SAM, SPC, SAS and SAT of T10.org.

Politics: "Nah, whatever you say, specs are *crap* and we'll
do it our way.  We are not interested in your way, even if it
were better.  Oh, and BTW, REQUEST SENSE clears ACA and LUN
is a u64."

See?
	Luben

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

[Greg Freemyer]

> >>> The way we do this is we slowly, without disruption to older
> >>> drivers introduce, in parallel, emerge a new, simpler, slimmer,
> >>> faster SCSI Core, whereby we accommodate new infrastructures,
> >>> yet, have 100% backward compatibility, via the current older SCSI
> >>> Core. After all, both would be a bunch of functions in a bunch of
> >>> files.
> >>
> >> Except this introduces bloat and multiplies maintainer load.  Fix the
> >> existing one.  If it breaks other in-core drivers, fix those to
> >
> > Well, not necessarily.  It would be more painful and more
> > maintainer load if we did what you suggest.  The overhead would be
> > enormous.
>
> So you're saying fixing the current SCSI subsystem once *now* costs
> more than applying all *future* SCSI fixes to _two_ SCSI subsystems,
> handling bug reports for _two_ SCSI subsystems, etc.
>

Luben has more than once called for adding a small number of
additional calls to the existing SCSI core.  These calls would
implement the new (reduced) functionallity.  The old calls would
continue to support the full SPI functionallity.  No existing  LLDD
would need modification.

Then, over time, more radical restructuring could be done that pulls
SPI out of SCSI core.

I believe this proposal is what he was talking about, not the brand
new simplified SCSI core that has been discussed recently in this
thread.

Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

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

[Luben Tuikov]

On 09/30/05 16:45, James Bottomley wrote:
> On Fri, 2005-09-30 at 14:34 -0400, Luben Tuikov wrote:
> 
>>James, Linus, can we have this driver in the kernel now, please?
> 
> 
> A while ago I told you that if you could show that the transport class
> abstraction could not support both the aic94xx and LSI SAS cards then we

I have, by example and by spec.  They both use two different
and distinct architectures.

Now _you_ have decided that this isn't the case, simply because
you want to prove your own idea.  (which breaks SAM layering)

I think I explained the similarity of the SAS Transport Layer
to *USB and SBP*.

As I said: everyone wants a pice of the SAS code.
You do too.

I'm sure you'll do whatever humanly possible to show
that _your_ idea can be applied: you can do this now:
just use a big if () { ... } else { ... } statement and
you're done.

Furthermore I do not see the reasons to umbrella both
"aic94xx and LSI cards" when they are _completely different_
in architecture: MPT and open transport (ala USB Storage and SBP).

> could look at doing SAS differently.  Since then you have asserted many
> times that a transport class could not work for the aic94xx (mostly by
> making inaccurate statements about what the transport class abstraction
> is) but have never actually provided any evidence for your assertion.

The code is here:
http://linux.adaptec.com/sas/

>>Now to things more pertinent, which I'm sure people are interested in:
>>
>>Jeff has been appointed to the role of integrating the SAS code
>>with the Linux SCSI _model_, with James Bottomley's "transport
>>attributes".
>>So you can expect more patches from him.
> 
> So very soon now, with proof by code, we shall have confirmation or
> negation of that assertion.  I'll wait quietly for this to happen, and I
> would suggest you do the same.

I just thought it was only fare to the rest of the community
to know how far the politics has escalated.

Everyone wants a piece of the SAS code.

	Luben

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

[Andre Hedrick]

On Fri, 30 Sep 2005, Luben Tuikov wrote:

> Hi Andre,
> 
> Let me know if this 4 section write up satisfies:

> Section 4: Politics
> -------------------
> 
> Let's face it: SAS is a new emerging technology.
> It will be the technology for the next 10-15 years,
> and *everybody* in Linux SCSI wants a piece of it.
> Everybody wants their name and contribution to it.

No true, many of us could careless about credit list.

> This is fine, but we need people who clearly understand
> the technology and clearly understand what, how
> and why it works.  We need well-read and well educated
> people.  Linux dedication is fine, but protocol knowlege
> is needed too.

Sometimes teaching others is a better way to bring them around to your
view point while learning about their goals.  Since everyone/most agree
your T10 knowledge is strong, others have pointed out you are savy enough
to work around problems over fixing them in general.  Blah blah ...

Just show everyone why it can not work the "Linux Way" and defend the
points logically.  Should the defense of it not be possible, then the
point is lost.

> Can Linux afford people who have never even read SAS
> to write SAS Code for Linux.  Yes, sure.  It is the
> Linux's ideology: "specs are cr@p".

SPECs become crap when organizations like STA with T10 make joining and
voting on the technology under NCITS $10,000.00 annual membership.  This
is old boys club rules, otherwise I would have joined and terrorized T10
like I did to T13.  Exclusion breeds distrust.

> Conclusion
> ----------
> 
> Even though the SAS Transport Layer follows an _already_
> establised layering infrastructure for more (less?) exotic
> transports such as USB and SBP, James Bottomley has resisted
> its inclusion in Linux SCSI.

If this is accurate then it is fair to raise a question; however, few can
stand in judgement because they were present in for the discussions.  The
remander (self included) are in the dark.

Cheers,

Andre

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

[Luben Tuikov]

On 09/30/05 17:15, Andrew Patterson wrote:
>>Sorry but I completely fail to see this argument., locks it, then hangs.
>>
>>How will it "fail for most storage managament apps"?
> 
> 
> Let's see, one example:
> 
> Process A opens an attribute and writes to it.  Process B opens another
> attribute and writes to it, affecting the result that process A will see
> from its subsequent read. I suppose you could lock every attribute, but
> that would be very error-prone, and not allow much concurrency.

Why should synchronization between Process A and Process B 
reading storage attributes take place in the kernel?

They can synchronize in user space.

	Luben

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

[Linus Torvalds]

On Fri, 30 Sep 2005, Matthew Wilcox wrote:
> 
> There's precedent for binary data in sysfs -- pci config space is one.

In general, if the data has no semantic meaning (ie it's just a blob), and 
there really is some point to exporting it, it should be exported as a 
binary blob. There's no point in doing some random "ASCII conversion" if 
the data doesn't have any known semantics. Bytes? Words? Longwords? 
Byteorder? It's simply not a sensible operation, and the only sane 
interface is to just read a binary blob with the raw data.

That's true in general of PCI config space. Of course, _some_ parts of PCI 
config space do indeed have meaning, so you'll find the "device" and 
"vendor" and other things like that as separate nodes in /sysfs with ASCII 
representations. So sometimes you may have mixtures (but it would be 
stupid to try to "remove" the semantic data from the blob - then it would 
turn into a _true_ monster).

So it's not like binary blobs are not allowed. In general, the rule should 
be:
 - all independent values should show up as independent files (never mix 
   stuff up that you don't need to)
 - anything with semantic meaning should have the appropriate semantic 
   textual format (ie formatted ASCII, not just raw data).

The _goal_ is that you can look at sysfs with a file manager, and the 
results should make sense. 

		Linus

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

[Joel Becker]

On Fri, Sep 30, 2005 at 03:15:50PM -0600, Andrew Patterson wrote:
> But again, this may be just a goal and not a hard and fast rule.  I can
> definitely see a use for binary attributes in sysfs. Configfs seems to
> be designed for this sort of thing.

	Configfs is designed for ascii or readable attributes.  It drops
the bin_attribute type that sysfs still supports.  So if you are looking
to fill a 64K binary attribute, configfs isn't the place you're going to
be going.

> > fd = open(smp_portal, ...);
> > write(fd, smp_req, smp_req_size);
> > read(fd, smp_resp, smp_resp_size);
> > close(fd);
> 
> Process A opens an attribute and writes to it.  Process B opens another
> attribute and writes to it, affecting the result that process A will see
> from its subsequent read. I suppose you could lock every attribute, but
> that would be very error-prone, and not allow much concurrency.

	Check out nfsctl.c and its transaction_file design.  process A
and process B get different buffers on filp->f_private, and cannot
influence each other's read/write operations.

Joel

-- 

Life's Little Instruction Book #347

	"Never waste the oppourtunity to tell someone you love them."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

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

[Kyle Moffett]

On Sep 30, 2005, at 15:08:15, Luben Tuikov wrote:
> On 09/30/05 14:50, Kyle Moffett wrote:
>> On Sep 30, 2005, at 14:34:42, Luben Tuikov wrote:
>>
>>> This is how we have the SPI-centric EH methods in the scsi host  
>>> template right now:
>>>    int (* eh_abort_handler)(struct scsi_cmnd *);
>>>    int (* eh_device_reset_handler)(struct scsi_cmnd *);
>>>    int (* eh_bus_reset_handler)(struct scsi_cmnd *);
>>>    int (* eh_host_reset_handler)(struct scsi_cmnd *);
>>
>> So submit patches to fix it!  You clearly understand what is  
>> wrong, so why not help change it?
>
> Because
>   - I do not want to give heart attack to all existing LLDDs

Significance of change is not an issue, assuming the change is broken  
up into a collection of small obvious changes as highlighted in  
Documentation/SubmittingPatches

>   - Some LLDD would never be able to be changed

Why not?  It's easy to change APIs, even stuff as invasive as the VM,  
the device driver model, etc, and those get changed all the time.

>   - Some LLDD work on very _scarce_ hardware which we cannot test.

You don't have to worry all that much about testing.  If your patches  
are small and obviously correct (like they should be), then they will  
get enough review during submission that there will only be a very  
small number of bugs.  The few remaining bugs will probably be ironed  
out in -mm.  In any case, if nobody uses hardware anymore, eventually  
the driver will get sufficiently crufty and out of date that it will  
be recognized as such and removed.

>   - plus such radical changes are neither warranted nor necessary.

Jeff Garzik et. al. seem to think that they are necessary, and I  
agree.  You don't need to fork SCSI-core; doing so would just double  
the maintainer load, and _that_ is neither warranted nor necessary.

> It is better to keep legacy around, until all you'll have on your  
> new serverboard is a SAS/SATA storage chip such as AIC-94xx or say  
> BCM8603.  Then you can compile out most of the legacy stuff.

Precisely.  When nobody uses the legacy drivers to the point that  
they aren't fixed or maintained anymore because no-one reports bugs,  
then said drivers can be removed from the kernel entirely, along with  
any support code.  The model I describe here works better because it  
keeps a _single_ clean core subsystem, and leaves any lack-of- 
maintenance crap in the old drivers.

> I think not breaking anything (for now at least) would be the  
> _easiest_ and most painless way to transition.

Until somebody wants to add a new high-level SCSI feature that works  
for both the new and the old devices.  Then they have to do it _twice_.

>>> The way we do this is we slowly, without disruption to older  
>>> drivers introduce, in parallel, emerge a new, simpler, slimmer,  
>>> faster SCSI Core, whereby we accommodate new infrastructures,  
>>> yet, have 100% backward compatibility, via the current older SCSI  
>>> Core. After all, both would be a bunch of functions in a bunch of  
>>> files.
>>
>> Except this introduces bloat and multiplies maintainer load.  Fix the
>> existing one.  If it breaks other in-core drivers, fix those to
>
> Well, not necessarily.  It would be more painful and more  
> maintainer load if we did what you suggest.  The overhead would be  
> enormous.

So you're saying fixing the current SCSI subsystem once *now* costs  
more than applying all *future* SCSI fixes to _two_ SCSI subsystems,  
handling bug reports for _two_ SCSI subsystems, etc.

>> s/Politics.*//g;  I hate politics.  Keep it off this list.
>
> Me too, but we are idealists.  Politics is an integral part of life.

Politics are not an integral part of productive technical  
discussions, though.  If you discuss technical topics and provide  
realistic technical descriptions, examples, reasons, code, etc, then  
politics tends not to matter in the discussion, and we're all happier  
people.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+ 
++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+ 
++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  !y?(-)
------END GEEK CODE BLOCK------

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

[Andrew Patterson]

On Fri, 2005-09-30 at 16:32 -0400, Luben Tuikov wrote:
> On 09/30/05 16:14, Andrew Patterson wrote:
> > 
> > Yes you can, which is what I am trying to do.  However, is that library
> > also available on Solaris and Windows? Is it up to date?  These are the
> 
> Is the kernel the latest one? Is it up to date?
> 
> See?  Same argument.
> 
> >>>Note that a sysfs implementation has problems.  Binary attributes are
> >>>discouraged/not-allowed.
> >>
> >>I've never heard that.  Is this similar to the argument
> >>"The sysfs tree would be too deep?"
> > 
> > 
> >>From Documentation/filesystes/sysfs.txt
> > 
> > "Attributes should be ASCII text files, preferably with only one value
> > per file. It is noted that it may not be efficient to contain only
> > value per file, so it is socially acceptable to express an array of
> > values of the same type.
> > 
> > Mixing types, expressing multiple lines of data, and doing fancy
> > formatting of data is heavily frowned upon. Doing these things may get
> > you publically humiliated and your code rewritten without notice."
> 
> I see this talk _only_ about non-binary attributes.

I think that "ASCII text files" implies non-binary. As Willy has pointed
out, this has already been violated.

> 
> Plus you have to admit: the SAS sysfs "smp_portal" binary
> attribute is very versatile: you completely control the
> expander from user space _if_ you can see it:  It is 
> almost like "point and click".

No problem with this.  

> 
> I imagine there would be GUIs built on top of it, which would
> actually implement that "point, click, control".
> 
> > My understanding is that sysfs is meant to be human-readable.  I do not
> 
> But `cat /sysfs/.../smp_portal` _is_ human readable.  See?  Its size is
> 0 bytes and when you read it you get 0 data read.

I don't quite think your definition of human readable is the same as
mine. I think the intention is to do something like:

$ cat attribute
3 Gb/s

or 

$ echo "3 Gb/s" >attribute

Rather than

$ cat attribute
gibberish.

or

$ echo "gibberish" >attribute

But again, this may be just a goal and not a hard and fast rule.  I can
definitely see a use for binary attributes in sysfs. Configfs seems to
be designed for this sort of thing.

> 
> > User space locking can only guarantee atomic operations in user space.  
> 
> And user space is the whole audience of this interface.
> 
> > Not sure at the moment, can I guarantee this for the future?
> 
> How far in the future? 1, 3, 6 months?  1, 3, 6 years?
> Plus if you need an attribute larger than 4K, you've got
> other problems to worry about.
> 
> > There are as many as one would want.  We now have 32 bit device numbers.
> > Old technology is fine as long as it works, especially if their is no
> > new technology to replace it.  Note that I don't like the character
> > device solution either. What would really be nice is something that will
> > allow us to pass an arbitrary request buffer, and get an arbitrary
> > response buffer back in a single transaction,
> , locks it, then hangs.
> Here:
> 
> /* User space lock */
> 
> fd = open(smp_portal, ...);
> write(fd, smp_req, smp_req_size);
> read(fd, smp_resp, smp_resp_size);
> close(fd);
> 
> /* User space unlock */
> 
> > See above.  This stuff works for trivial user-space apps.  It will not
> > suffice for most storage management apps.  
> 
> Sorry but I completely fail to see this argument., locks it, then hangs.
> 
> How will it "fail for most storage managament apps"?

Let's see, one example:

Process A opens an attribute and writes to it.  Process B opens another
attribute and writes to it, affecting the result that process A will see
from its subsequent read. I suppose you could lock every attribute, but
that would be very error-prone, and not allow much concurrency.

Andrew

> 
> 	Luben
> 

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

[James Bottomley]

On Fri, 2005-09-30 at 14:34 -0400, Luben Tuikov wrote:
> James, Linus, can we have this driver in the kernel now, please?

A while ago I told you that if you could show that the transport class
abstraction could not support both the aic94xx and LSI SAS cards then we
could look at doing SAS differently.  Since then you have asserted many
times that a transport class could not work for the aic94xx (mostly by
making inaccurate statements about what the transport class abstraction
is) but have never actually provided any evidence for your assertion.

In a recent prior email, you said:

> Now to things more pertinent, which I'm sure people are interested in:
> 
> Jeff has been appointed to the role of integrating the SAS code
> with the Linux SCSI _model_, with James Bottomley's "transport
> attributes".
> So you can expect more patches from him.

So very soon now, with proof by code, we shall have confirmation or
negation of that assertion.  I'll wait quietly for this to happen, and I
would suggest you do the same.

James

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

[Luben Tuikov]

On 09/30/05 16:14, Andrew Patterson wrote:
> 
> Yes you can, which is what I am trying to do.  However, is that library
> also available on Solaris and Windows? Is it up to date?  These are the

Is the kernel the latest one? Is it up to date?

See?  Same argument.

>>>Note that a sysfs implementation has problems.  Binary attributes are
>>>discouraged/not-allowed.
>>
>>I've never heard that.  Is this similar to the argument
>>"The sysfs tree would be too deep?"
> 
> 
>>From Documentation/filesystes/sysfs.txt
> 
> "Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only
> value per file, so it is socially acceptable to express an array of
> values of the same type.
> 
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publically humiliated and your code rewritten without notice."

I see this talk _only_ about non-binary attributes.

Plus you have to admit: the SAS sysfs "smp_portal" binary
attribute is very versatile: you completely control the
expander from user space _if_ you can see it:  It is 
almost like "point and click".

I imagine there would be GUIs built on top of it, which would
actually implement that "point, click, control".

> My understanding is that sysfs is meant to be human-readable.  I do not

But `cat /sysfs/.../smp_portal` _is_ human readable.  See?  Its size is
0 bytes and when you read it you get 0 data read.

> User space locking can only guarantee atomic operations in user space.  

And user space is the whole audience of this interface.

> Not sure at the moment, can I guarantee this for the future?

How far in the future? 1, 3, 6 months?  1, 3, 6 years?
Plus if you need an attribute larger than 4K, you've got
other problems to worry about.

> There are as many as one would want.  We now have 32 bit device numbers.
> Old technology is fine as long as it works, especially if their is no
> new technology to replace it.  Note that I don't like the character
> device solution either. What would really be nice is something that will
> allow us to pass an arbitrary request buffer, and get an arbitrary
> response buffer back in a single transaction,

Here:

/* User space lock */

fd = open(smp_portal, ...);
write(fd, smp_req, smp_req_size);
read(fd, smp_resp, smp_resp_size);
close(fd);

/* User space unlock */

> See above.  This stuff works for trivial user-space apps.  It will not
> suffice for most storage management apps.  

Sorry but I completely fail to see this argument.

How will it "fail for most storage managament apps"?

	Luben

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

[Matthew Wilcox]

On Fri, Sep 30, 2005 at 02:14:50PM -0600, Andrew Patterson wrote:
> > > Note that a sysfs implementation has problems.  Binary attributes are
> > > discouraged/not-allowed.
> > 
> > I've never heard that.  Is this similar to the argument
> > "The sysfs tree would be too deep?"
> 
> >From Documentation/filesystes/sysfs.txt
> 
> "Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only
> value per file, so it is socially acceptable to express an array of
> values of the same type.
> 
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publically humiliated and your code rewritten without notice."
> 
> My understanding is that sysfs is meant to be human-readable.  I do not
> know if this is a hard and fast rule or just a convention.  Configfs is
> probably a better fit at least for writeable attributes, but may not be
> cooked yet.

There's precedent for binary data in sysfs -- pci config space is one.

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

[Andrew Patterson]

On Fri, 2005-09-30 at 15:21 -0400, Luben Tuikov wrote:
> On 09/30/05 14:39, Andrew Patterson wrote:
> > 
> > SDI is supposed to be a cross-platform spec, so mandating sysfs would
> > not work.
> 
> True, sysfs is a Linux only thing.
> 
> But you can write a user space library which uses sysfs or whatever
> _that_ OS uses to represent an SDI spec-ed out picture.

Yes you can, which is what I am trying to do.  However, is that library
also available on Solaris and Windows? Is it up to date?  These are the
reasons why the spec authors rejected that approach. I don't agree with
them BTW, but I do understand why they think that way.

> 
> So a user space program would call (uniformly across all OSs)
> a libsdi library which will use whatever OS dependent way there is
> to get the information (be it sysfs or ioctl).

See the paragraph below.

> 
> > I suggested to the author to use a library like HPAAPI (used
> > by Fibre channel), so you could hide OS implementation details.  I am in
> > fact working on such a beasty (http://libsdi.berlios.de).  He thinks
> > that library solutions tend to not work, because the library version is
> > never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> > he does have a valid point.
> 
> Yes, but it would be the best of all the current ways there are
> to do it.

Theoretically yes.  Practically, perhaps not.  The authors seem to have
been left with a bad taste in their mouths after their experience with
HBA API.  They agree that IOCTL are bad too do to lack of linux support,
but do not have a better cross-platform solution as yet.  The current
way around this is to use CSMI and brow-beat various Linux vendors into
allowing these IOCTL's into their kernels.

> 
> > Note that a sysfs implementation has problems.  Binary attributes are
> > discouraged/not-allowed.
> 
> I've never heard that.  Is this similar to the argument
> "The sysfs tree would be too deep?"

>From Documentation/filesystes/sysfs.txt

"Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only
value per file, so it is socially acceptable to express an array of
values of the same type.

Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publically humiliated and your code rewritten without notice."

My understanding is that sysfs is meant to be human-readable.  I do not
know if this is a hard and fast rule or just a convention.  Configfs is
probably a better fit at least for writeable attributes, but may not be
cooked yet.

> 
> > There is no atomic request/response operations
> 
> For a reason: let user space do it, there is plenty of ways to
> do it, some assisted by the kernel.

User space locking can only guarantee atomic operations in user space.  

> 
> > buffers limited to page size, etc.
> 
> "You have an attribute larger than 4k?  What is it?"

Not sure at the moment, can I guarantee this for the future?

> 
> As to SMP response/request is more than 4K/8K?  The largest
> I'm aware of is 64 bytes.
> 
> > Other alternatives are
> > configfs, SG_IO, and the above mentioned character device.  None are a
> 
> Again, char devices for controlling are discouraged.  There are not enough
> around and it is old technology.

There are as many as one would want.  We now have 32 bit device numbers.
Old technology is fine as long as it works, especially if their is no
new technology to replace it.  Note that I don't like the character
device solution either. What would really be nice is something that will
allow us to pass an arbitrary request buffer, and get an arbitrary
response buffer back in a single transaction,  SG_IO comes closest, but
shares request/response buffers and is limited to a 16-byte commands.
It also requires a device file.

> 
> > complete replacement for the transactional nature of IOCTL's.  A group
> 
> Here:
> 
> /* User space lock */
> 
> fd = open(smp_portal, ...);
> write(fd, smp_req, smp_req_size);
> read(fd, smp_resp, smp_resp_size);
> close(fd);
> 
> /* User space unlock */
> 

See above.  This stuff works for trivial user-space apps.  It will not
suffice for most storage management apps.  

Andrew


> 	Luben
> 

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

[Bob Copeland]

[cc trimmed]

> I think a better explanation of 'scientific theory' is:
>
> an explanation or definition of observed behaviour with no known error

...that is testable.  (Not that this has anything to do with the point.)

While jumping on the thread for no good reason, I might point out (to
Luben) that ^w is erase word and ^h is erase character.  Your stty
settings may vary.

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

[Luben Tuikov]

On 09/30/05 14:39, Andrew Patterson wrote:
> 
> SDI is supposed to be a cross-platform spec, so mandating sysfs would
> not work.

True, sysfs is a Linux only thing.

But you can write a user space library which uses sysfs or whatever
_that_ OS uses to represent an SDI spec-ed out picture.

So a user space program would call (uniformly across all OSs)
a libsdi library which will use whatever OS dependent way there is
to get the information (be it sysfs or ioctl).

> I suggested to the author to use a library like HPAAPI (used
> by Fibre channel), so you could hide OS implementation details.  I am in
> fact working on such a beasty (http://libsdi.berlios.de).  He thinks
> that library solutions tend to not work, because the library version is
> never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> he does have a valid point.

Yes, but it would be the best of all the current ways there are
to do it.

> Note that a sysfs implementation has problems.  Binary attributes are
> discouraged/not-allowed.

I've never heard that.  Is this similar to the argument
"The sysfs tree would be too deep?"

> There is no atomic request/response operations

For a reason: let user space do it, there is plenty of ways to
do it, some assisted by the kernel.

> buffers limited to page size, etc.

"You have an attribute larger than 4k?  What is it?"

As to SMP response/request is more than 4K/8K?  The largest
I'm aware of is 64 bytes.

> Other alternatives are
> configfs, SG_IO, and the above mentioned character device.  None are a

Again, char devices for controlling are discouraged.  There are not enough
around and it is old technology.

> complete replacement for the transactional nature of IOCTL's.  A group

Here:

/* User space lock */

fd = open(smp_portal, ...);
write(fd, smp_req, smp_req_size);
read(fd, smp_resp, smp_resp_size);
close(fd);

/* User space unlock */

	Luben

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

[Joe Bob Spamtest]

Marcin Dalecki wrote:
> On 2005-09-30, at 02:35, Linus Torvalds wrote:
>> A scientific theory is an approximation of observed behaviour WITH NO
>> KNOWN HOLES.
> 
> Since "approximation" is equivalent to a "known hole", there is no  
> single scientific theory without known holes out there?! Well that's  a 
> segfault in brain - unless you don't consider math science of course.
> 
> A scientific theory is just a set of axioms and deduction rules. Not  
> much more by definition...

I think a better explanation of 'scientific theory' is:

an explanation or definition of observed behaviour with no known error

which, is what I believe Linus was trying to say

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

[Luben Tuikov]

On 09/30/05 14:50, Kyle Moffett wrote:
> On Sep 30, 2005, at 14:34:42, Luben Tuikov wrote:
> 
>>This is how we have the SPI-centric EH methods in the scsi host  
>>template right now:
>>    int (* eh_abort_handler)(struct scsi_cmnd *);
>>    int (* eh_device_reset_handler)(struct scsi_cmnd *);
>>    int (* eh_bus_reset_handler)(struct scsi_cmnd *);
>>    int (* eh_host_reset_handler)(struct scsi_cmnd *);
> 
> 
> So submit patches to fix it!  You clearly understand what is wrong,  
> so why not help change it?

Because
  - I do not want to give heart attack to all existing LLDDs
  - Some LLDD would never be able to be changed
  - Some LLDD work on very _scarce_ hardware which we cannot test.
  - plus such radical changes are neither warranted nor necessary.

It is better to keep legacy around, until all you'll have on
your new serverboard is a SAS/SATA storage chip such as
AIC-94xx or say BCM8603.  Then you can compile out most
of the legacy stuff.

>>But we should _not_ break legacy drivers and backward support,
> 
> WRONG.  This is not the way Linux works.  We break internal APIs all  
> the time.  If you need to change one _thats_OK_.  Userspace ABI is  

Well, I can never have it right.  Some people say you shouldn't break
it, others say let's break the whole thing and give heart attack
to all LLDDs, other say it is impossible to change all LLDD since
the hardware is not around, etc, etc.

I think not breaking anything (for now at least) would be the
_easiest_ and most painless way to transition.

>>The way we do this is we slowly, without disruption to older  
>>drivers introduce, in parallel, emerge a new, simpler, slimmer,  
>>faster SCSI Core, whereby we accommodate new infrastructures, yet,  
>>have 100% backward compatibility, via the current older SCSI Core.   
>>After all, both would be a bunch of functions in a bunch of files.
> 
> 
> Except this introduces bloat and multiplies maintainer load.  Fix the  
> existing one.  If it breaks other in-core drivers, fix those to  

Well, not necessarily.  It would be more painful and more maintainer
load if we did what you suggest.  The overhead would be enormous.

>>Section 4: Politics
>>-------------------
> 
> 
> s/Politics.*//g;  I hate politics.  Keep it off this list.

Me too, but we are idealists.  Politics is an integral part of
life.

Long time ago, in a galaxy far, far away...
I literally sat in a meeting whereby technical staff of _several_
companies agreed that Pi=3.0.

	Luben

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

[Luben Tuikov]

On 09/30/05 03:36, Andre Hedrick wrote:
> I stated I would help with SAS adoption because there is a SAS-Transport
> model.  I asked about a possible libadaptec + libsas, and still waiting to
> see if you and adaptec are up for the task.  Right now the only path open
> is the one Jeff Garzik is putting forward along with James and Christop.
> I have a vested interest in seeing SAS-Transport, otherwise I would have
> cut and run a long time ago.

Hi Andre,

Let me know if this satisfies:

The infrastructure is broken into
	* SAS LLDD,
	* SAS Layer.

The SAS LLDD does phy/OOB management, and generates SAS events
to the SAS Layer.  Those events are *the only way* a SAS LLDD
communicates with the SAS Layer.  If you can generate 2 types
of event, then you can use this infrastructure.  The first two
are, loosely, "link was severed", "bytes were dmaed".  The third
kind is "received a primitive", used for domain revalidation.

A SAS LLDD should implement the Execute Command SCSI RPC and
at least one SCSI TMF (Task Management Function), in order for
the SAS Layer to communicate with the SAS LLDD.

The SAS Layer is concerned with
      * SAS Phy/Port/HA event management (LLDD generates,
        SAS Layer processes),
      * SAS Port management (creation/destruction),
      * SAS Domain discovery and revalidation,
      * SAS Domain device management,
      * SCSI Host registration/deregistration,
      * Device registration with SCSI Core (SAS) or libata
        (SATA/PI), and
      * Expander management and exporting expander control
        to user space.

The SAS Layer uses the Execute Command SCSI RPC, and the TMFs
implemented by the SAS LLDD in order to manage the domain and
the domain devices.

For details please see drivers/scsi/sas/README.

The SAS Layer represents the SAS domain in sysfs.  For each
object represented, its parent is the physical entity it attaches
to in the physical world.  So in effect, kobject_get, gets
the whole chain up on which that object depends on.

In effect, the sysfs representation of the SAS domain(s)
is what you'd see in the physical world.

Hot plugging and hot unplugging of devices, domains and subdomains
is supported.  Repeated hot plugging and hot unplugging is
also supported, naturally.

SAS introduces a new physical entity, an expander.
Expanders are _not_ SAS devices, and thus are _not_ SCSI devices.
Expanders are part of the Service Delivery Subsystem, in this case
SAS.

Expanders are controlled using the Serial Management Protocol (SMP).
Complete control is given to user space of all expanders found
in the domain, using an "smp_portal".  More of this in the second
and third email in this series.

A user space program, "expander_conf.c" is also presented to show
how one controls expanders in the domain.  It is located here:
drivers/scsi/sas/expanders_conf.c

Thank you,
	Luben

> 
> These long email threads where everyone is shout from the top of their
> hill never wins anything.  After a while the hill becomes flat (from all
> the stomping), and you become old and tired.
> 
> LSI pointed out they mask there SAS in firmware and make it show up in a
> scsi-like or scsi state.  They also pointed out other vendors have taken
> this road.  Even if Adaptec did not go this way in hardware, there still
> has to be a way to map into SCSI ... sheesh this is Adaptec known for
> SCSI.
> 
> Just an FYI, would suggest you cool your heels and listen for the quiet
> responses.  There is more heat than light right now; maybe this thread
> will offset some of the cost in the energy criss.  Will pass on advice
> handed to me (when I was a maintainer) relax and listen, nobody is out to
> get you (and they were right).
> 
> Cheers,
> 
> Andre
> 
> PS I didn't listen to that advice back then, don't make the same mistake.
> 
> 
> 

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

[Kyle Moffett]

On Sep 30, 2005, at 14:34:42, Luben Tuikov wrote:
> This is how we have the SPI-centric EH methods in the scsi host  
> template right now:
>     int (* eh_abort_handler)(struct scsi_cmnd *);
>     int (* eh_device_reset_handler)(struct scsi_cmnd *);
>     int (* eh_bus_reset_handler)(struct scsi_cmnd *);
>     int (* eh_host_reset_handler)(struct scsi_cmnd *);

So submit patches to fix it!  You clearly understand what is wrong,  
so why not help change it?

> But we should _not_ break legacy drivers and backward support,

WRONG.  This is not the way Linux works.  We break internal APIs all  
the time.  If you need to change one _thats_OK_.  Userspace ABI is  
mostly another matter, but that's different from the internal data  
structures and functions.

> The way we do this is we slowly, without disruption to older  
> drivers introduce, in parallel, emerge a new, simpler, slimmer,  
> faster SCSI Core, whereby we accommodate new infrastructures, yet,  
> have 100% backward compatibility, via the current older SCSI Core.   
> After all, both would be a bunch of functions in a bunch of files.

Except this introduces bloat and multiplies maintainer load.  Fix the  
existing one.  If it breaks other in-core drivers, fix those to  
match.  If it breaks out-of-tree drivers, too bad!  They should get  
their code upstream and then they wouldn't need to worry.

> If X works with Y, do not disrupt it.  Fix it if it's broken.   
> Introduce innovation, functionality, better design, but not at the  
> expense of breaking legacy.

This is not the way Linux works.  It may be the way Adaptec works,  
but that's not relevant here.

> Section 4: Politics
> -------------------

s/Politics.*//g;  I hate politics.  Keep it off this list.

Cheers,
Kyle Moffett

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

[Andrew Patterson]

On Fri, 2005-09-30 at 13:07 -0400, Salyzyn, Mark wrote:
> At the SAS BOF, I indicated that it would not be much trouble to
> translate the CSMI handler in the aacraid driver to a similar sysfs
> arrangement. If such info can be mined from a firmware based RAID card,
> every driver should be able to do so. The spec writers really need to
> consider rewriting SDI for sysfs (if they have not already) and move
> away from an ABI.

SDI is supposed to be a cross-platform spec, so mandating sysfs would
not work.  I suggested to the author to use a library like HPAAPI (used
by Fibre channel), so you could hide OS implementation details.  I am in
fact working on such a beasty (http://libsdi.berlios.de).  He thinks
that library solutions tend to not work, because the library version is
never in synch with the standard/LLDD's. Given Linux vendor lead-times,
he does have a valid point.

Note that a sysfs implementation has problems.  Binary attributes are
discouraged/not-allowed.  There is no atomic request/response
operations, buffers limited to page size, etc. Other alternatives are
configfs, SG_IO, and the above mentioned character device.  None are a
complete replacement for the transactional nature of IOCTL's.  A group
of us are looking into this.  We probably should be taking it to
linux-scsi, but didn't want to get it caught up in the current flamewar.

Andrew

> 
> Sincerely -- Mark Salyzyn
> 
> -----Original Message-----
> From: Tuikov, Luben
> Sent: Friday, September 30, 2005 12:47 PM
> To: andrew.patterson@hp.com
> Cc: dougg@torque.net; Linus Torvalds; Luben Tuikov; SCSI Mailing List;
> Linux Kernel Mailing List
> Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx
> into the kernel
> 
> On 09/30/05 12:26, Andrew Patterson wrote:
> > 
> > I talked to one of the authors of these specs.  SDI is an attempt to 
> > create an open standard for the somewhat proprietary CSMI spec 
> > developed by HP.  It is currently languishing in t10 due to the IOCTL 
> > problem you describe below (the "no new IOCTL's" doctrine caught them 
> > by surprise). There is some thought to going to a write()/read() on a 
> > character device model, but this has various problems as well.
> 
> I think that read/write from a char device is going away too.
> 
> For this reason I showed the whole picture of the SAS
> domain in sysfs _and_ created a binary file attr to send/receive SMP
> requests/responses to control the domain and get attributes
> ("smp_portal" binary attr of each expander).
> 
> It is completely user space driven and a user space library
> is simple to write.
> 
> See drivers/scsi/sas/expander_conf.c which is a user
> space utility.  For the output see Announcement 3:
> http://linux.adaptec.com/sas/Announce_2.txt or here:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2
> 
> The code which implements it is very tiny, at the bottom
> of drivers/scsi/sas/sas_expander.c
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Luben Tuikov]

On 09/30/05 03:36, Andre Hedrick wrote:
> I stated I would help with SAS adoption because there is a SAS-Transport
> model.  I asked about a possible libadaptec + libsas, and still waiting to
> see if you and adaptec are up for the task.  Right now the only path open
> is the one Jeff Garzik is putting forward along with James and Christop.
> I have a vested interest in seeing SAS-Transport, otherwise I would have
> cut and run a long time ago.
> 
> These long email threads where everyone is shout from the top of their
> hill never wins anything.  After a while the hill becomes flat (from all
> the stomping), and you become old and tired.
> 
> LSI pointed out they mask there SAS in firmware and make it show up in a
> scsi-like or scsi state.  They also pointed out other vendors have taken
> this road.  Even if Adaptec did not go this way in hardware, there still
> has to be a way to map into SCSI ... sheesh this is Adaptec known for
> SCSI.

Hi Andre,

Let me know if this 4 section write up satisfies:

Section 1: MPT, SCSI Core and JB's "transport attributes"
---------------------------------------------------------

SPI drivers (say 5 years ago)
-----------------------------
 hardware implementation     (bus connect)
     firmware implementation   (transport: SPI)
        LLDD                     (exports SCSI devices (LUs))
           SCSI Core
              Command Sets


MPT-based drivers (now)
-----------------------
 hardware implementation     (interconnect/physical)
-->  Transport Layer           (firmware: FC/SPI/SAS/etc)  <--
        LLDD                     (exports SCSI devices (LUs))
           SCSI Core
              Command Sets

As you can see SCSI Core is _unaware_ of the transport.
The transport is completely implemented in FIRMWARE, relieving
the LLDD from worrying about it.  Theoretically/ideally the same
LLDD would work for _all_ transports, since the FW would
export LUs to the LLDD, which would in turn register
those with SCSI Core.

The layout is the same as before, achieving 100% backward
software compatibility.


MPT-based drivers + James Bottomley's "transport attributes"
-------------------------------------------------------------
 hardware implementation
     Transport Layer               <------+ FW/Transport dependent access method
        LLDD                  <---------- + LLDD dependent access method
           SCSI Core ---------------------'
              Command Sets

This picture is _identical_ to the one above, but
I've also shown what the "transport attributes" achieve:
They hook to the _LLDD_ to get to LLDD dependent way of
accessing "transport attributes" (any transport).  This is
JB's template unifying _all_ transports.

Note that this isn't a _management_ layer or infrastructure,
since, it _does not lie between_ the LLDD and SCSI Core.
It merely implements attribute exporting.


Section 2: USB/SBP/SAS and SCSI Core
------------------------------------

  hardware implementation            (interconnect/physical)
      firmware implementation           (SDS: TMFs + Execute Command SCSI RPC)*
          LLDD                             (Coherent interface to SDS)
-->         Transport Layer                   (Transport common to LLDDs) <--
                 SCSI Core
                    Command Sets

* SDS, Service Delivery Subsystem (see SAM 4.6)
  TMF, Task Management Function (see SAM 7)
  Execute Command SCSI RPC (see SAM 5.1)

Most immediate difference from Section 1 is that
  - the Transport Layer is _above_ the LLDD (in top-down).
  - no need for LLDD/Firmware dependent access method
    to the Transport,
  - Transport is accessed in the same way across all
    LLDDs of the same transport (USB/SBP/SAS).

Now since, the LLDDs all implement TMFs + Exec Cmnd SCSI RPC,
you can have 
  - a transport common error handling and
  - a transport common "attribute" access (sysfs),
across all LLDD of the same transport directly from userspace.

The reason the LLDDs all implement TMFs + Exec Cmnd SCSI RPC,
is that the Firmware implements it, and the reason that
the Firmware implements it is that the chip implements
it (following the transport spec).

That is, you can have _different_ LLDDs connecting you
to the _same place_ (maybe not at the same time, depending
on the transport).

SCSI Core should be completely unaware of the
Transport being used and Transport specific
Error handling is common to all such Transport
specific LLDDs (via TMFs): one for SBP, one for
USB, one for SAS. 

The whole point of this USB/SBP/SAS Transport
Layering is that you can access at each level,
thus you can add new abstractions, e.g. SATL (libata),
as is shown in the SATr06 spec.

Furthermore, when you look at the USB/SBP/SAS chips
you will see nothing about "scsi_host", and all about
"transport".

And the sysfs representation of the SAS domain is analogous
to, say, the USB representation of the USB domain.


Section 3: Legacy Thinking or Thinking Legacy
---------------------------------------------

Traditionally Error Handling has been done in
SCSI Core.  The reason for this is that the first
and only SCSI was Parallel SCSI and no other
SCSI was around (and that SAM didn't exist back then).

This is how we have the SPI-centric EH methods
in the scsi host template right now:
	int (* eh_abort_handler)(struct scsi_cmnd *);
	int (* eh_device_reset_handler)(struct scsi_cmnd *);
	int (* eh_bus_reset_handler)(struct scsi_cmnd *);
	int (* eh_host_reset_handler)(struct scsi_cmnd *);

This is fine for Parallel SCSI (SPI) but for other
transports it doesn't quite satisfy.

Let's admit it, with HCIL and with the EH, SCSI Core
is still very SPI centric.

But we should _not_ break legacy drivers and backward
support, yet we have to face the future.

The way we do this is we slowly, without disruption
to older drivers introduce, in parallel, emerge
a new, simpler, slimmer, faster SCSI Core, whereby
we accommodate new infrastructures, yet, have 100%
backward compatibility, via the current older
SCSI Core.  After all, both would be a bunch of
functions in a bunch of files.

If X works with Y, do not disrupt it.  Fix it if
it's broken.  Introduce innovation, functionality,
better design, but not at the expense of breaking
legacy.

To eliminate bugs, tweak old as little as possible,
since you cannot test on _all_ hardware the old code
works on.

To achieve maximum innovation and relevance in the fast
changing world of storage, create, innovate new
better, more accommodating design and infrastructures.

Section 4: Politics
-------------------

Let's face it: SAS is a new emerging technology.
It will be the technology for the next 10-15 years,
and *everybody* in Linux SCSI wants a piece of it.
Everybody wants their name and contribution to it.

This is fine, but we need people who clearly understand
the technology and clearly understand what, how
and why it works.  We need well-read and well educated
people.  Linux dedication is fine, but protocol knowlege
is needed too.

Can Linux afford people who have never even read SAS
to write SAS Code for Linux.  Yes, sure.  It is the
Linux's ideology: "specs are cr@p".

Conclusion
----------

Even though the SAS Transport Layer follows an _already_
establised layering infrastructure for more (less?) exotic
transports such as USB and SBP, James Bottomley has resisted
its inclusion in Linux SCSI.

Have we lost our touch with the new calling it
"non-traditional"?  Will Linux become a dinosaur?

I'm not sure how many times one can split the SAS code?
Will there be enough for everyone?

> Just an FYI, would suggest you cool your heels and listen for the quiet
> responses.  There is more heat than light right now; maybe this thread
> will offset some of the cost in the energy criss.  Will pass on advice
> handed to me (when I was a maintainer) relax and listen, nobody is out to
> get you (and they were right).

Thank you Andre for the warm advice.

James, Linus, can we have this driver in the kernel now, please?

Thank you,
	Luben

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

[Joe Bob Spamtest]

Luben Tuikov wrote:
> Hardware folks needs to work with software folks and
> software folks need to work with hardware folks.
> 
> This is what makes good design.

This is so true, and so often overlooked when hardware is being designed 
and built. A lot of it can be attributed to mismanagement and bad 
communication between departments ... But, that's the drawback of the 
corporate system

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

[Arjan van de Ven]

On Fri, 2005-09-30 at 13:07 -0400, Salyzyn, Mark wrote:
> At the SAS BOF, I indicated that it would not be much trouble to
> translate the CSMI handler in the aacraid driver to a similar sysfs
> arrangement. If such info can be mined from a firmware based RAID card,
> every driver should be able to do so. The spec writers really need to
> consider rewriting SDI for sysfs (if they have not already) and move
> away from an ABI.

that makes me wonder... why and how does T10 control linux abi's ??

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

[Salyzyn, Mark]

At the SAS BOF, I indicated that it would not be much trouble to
translate the CSMI handler in the aacraid driver to a similar sysfs
arrangement. If such info can be mined from a firmware based RAID card,
every driver should be able to do so. The spec writers really need to
consider rewriting SDI for sysfs (if they have not already) and move
away from an ABI.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Tuikov, Luben
Sent: Friday, September 30, 2005 12:47 PM
To: andrew.patterson@hp.com
Cc: dougg@torque.net; Linus Torvalds; Luben Tuikov; SCSI Mailing List;
Linux Kernel Mailing List
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx
into the kernel

On 09/30/05 12:26, Andrew Patterson wrote:
> 
> I talked to one of the authors of these specs.  SDI is an attempt to 
> create an open standard for the somewhat proprietary CSMI spec 
> developed by HP.  It is currently languishing in t10 due to the IOCTL 
> problem you describe below (the "no new IOCTL's" doctrine caught them 
> by surprise). There is some thought to going to a write()/read() on a 
> character device model, but this has various problems as well.

I think that read/write from a char device is going away too.

For this reason I showed the whole picture of the SAS
domain in sysfs _and_ created a binary file attr to send/receive SMP
requests/responses to control the domain and get attributes
("smp_portal" binary attr of each expander).

It is completely user space driven and a user space library
is simple to write.

See drivers/scsi/sas/expander_conf.c which is a user
space utility.  For the output see Announcement 3:
http://linux.adaptec.com/sas/Announce_2.txt or here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2

The code which implements it is very tiny, at the bottom
of drivers/scsi/sas/sas_expander.c

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

[Luben Tuikov]

On 09/30/05 12:26, Andrew Patterson wrote:
> 
> I talked to one of the authors of these specs.  SDI is an attempt to
> create an open standard for the somewhat proprietary CSMI spec developed
> by HP.  It is currently languishing in t10 due to the IOCTL problem you
> describe below (the "no new IOCTL's" doctrine caught them by surprise).
> There is some thought to going to a write()/read() on a character device
> model, but this has various problems as well.  

I think that read/write from a char device is going away too.

For this reason I showed the whole picture of the SAS
domain in sysfs _and_ created a binary file attr to
send/receive SMP requests/responses to control
the domain and get attributes ("smp_portal" binary
attr of each expander).

It is completely user space driven and a user space library
is simple to write.

See drivers/scsi/sas/expander_conf.c which is a user
space utility.  For the output see Announcement 3:
http://linux.adaptec.com/sas/Announce_2.txt or here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2

The code which implements it is very tiny, at the bottom
of drivers/scsi/sas/sas_expander.c

>>Sorry, did I mention "ioctl",
>>oh that makes SDI unacceptable. Almost a year ago that is what
>>happened to the first proposed SAS driver for Linux. 
> 
> 
> That was one of the reasons the MPT Fusion and Adaptec drivers were
> rejected.  There were others as well, such as lack of a SAS transport
> class.

You mean the first Adaptec SAS "adp94xx" driver.

BTW, neither the original "adp94xx", nor the subsequent "aic94xx"
Adaptec drivers implmented _any_ ioctls for CSMI/SDI.

	Luben

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

[Andrew Patterson]

On Fri, 2005-09-30 at 17:29 +1000, Douglas Gilbert wrote:

snippage.

> 
> For SAS we have a well thought out definition for what the
> interface should be to hardware specific drivers IMO. It is
> called CSMI, rechristened SDI. The editor of SDI is also
> the editor of SAS, SAS-1.1 and SAS-2. Judging from his work,
> he knows his stuff. Unfortunately SDI uses ioctls to define
> its interface, which is mainly between two kernel layers
> (if one ignores pass throughs). 

I talked to one of the authors of these specs.  SDI is an attempt to
create an open standard for the somewhat proprietary CSMI spec developed
by HP.  It is currently languishing in t10 due to the IOCTL problem you
describe below (the "no new IOCTL's" doctrine caught them by surprise).
There is some thought to going to a write()/read() on a character device
model, but this has various problems as well.  

> Sorry, did I mention "ioctl",
> oh that makes SDI unacceptable. Almost a year ago that is what
> happened to the first proposed SAS driver for Linux. 

That was one of the reasons the MPT Fusion and Adaptec drivers were
rejected.  There were others as well, such as lack of a SAS transport
class.

Andrew

> That
> decision has pushed Luben (amongst others) into the position
> he is in now: come up with a "better" design, produce code
> and then watch it get rejected. So please cut Luben a bit
> of slack.
> 
> Just in case people think that I agree with Luben on using
> sysfs to represent the whole SAS topology and interesting
> bits suspended in it (i.e. SAS expanders), then I don't.
> I am, however, prepared to argue the detail. Since the
> days of Eric Youngdale I have believed that SCSI Host Bus
> Adapters (HBAs) should be addressable devices, just like
> network interfaces. IMO it is the block layer and its
> associated end devices that are the legacy thinking.
> 
> > There's an absolutely mindbogglingly huge difference between the two.
> 
> It is ironic that as the author of the SG_IO
> passthrough ioctl the "specs" that I am
> often asked to help circumvent are the "we
> know better" variety built into various layers
> of the linux kernel :-)
> 
> Doug Gilbert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Luben Tuikov]

On 09/30/05 03:29, Douglas Gilbert wrote:
> 
> For SAS we have a well thought out definition for what the
> interface should be to hardware specific drivers IMO. It is
> called CSMI, rechristened SDI. The editor of SDI is also
> the editor of SAS, SAS-1.1 and SAS-2. Judging from his work,
> he knows his stuff. Unfortunately SDI uses ioctls to define
> its interface, which is mainly between two kernel layers
> (if one ignores pass throughs). Sorry, did I mention "ioctl",

Hi Doug,

Almost all of the SDI stuff can be extracted by a user space
library reading the SAS sysfs domain tree (which is the result
of domain discovery).

Pictures of can be found here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509826900&w=2

Since MPT-based hardware does domain discovery in the FIRMWARE,
this is why you do not have the domain picture as easily.

> oh that makes SDI unacceptable. Almost a year ago that is what
> happened to the first proposed SAS driver for Linux. That
> decision has pushed Luben (amongst others) into the position
> he is in now: come up with a "better" design, produce code
> and then watch it get rejected. So please cut Luben a bit
> of slack.

What James Bottomley et al. complained back then is that
"common code" to SAS should be pulled out in a "common layer".

This layer is the SAS Transport layer.

But in the mean time, LSI came out with SAS, whose driver
as you can see had nothing to do with SAS -- it was an MPT
driver after all, so James Bottomley decides that whatever
else comes along, it would use _his_ design.  Whether it
works for open transport, he doesn't want to listen.  He
is using his political power to enforce it.

> Just in case people think that I agree with Luben on using
> sysfs to represent the whole SAS topology and interesting
> bits suspended in it (i.e. SAS expanders), then I don't.
> I am, however, prepared to argue the detail. Since the

Sorry, since the discover process keeps an internal
representation of "what is out there" via discovery,
I just tacked a kobject to each structure I have anyway,
and showed it in sysfs.

I thought that was the whole purpose of sysfs -- to show
kernel internal structures and dependencies.

Plus, this is what it _actually_ looks in the physical world.

Also you have to admit -- it looks cool:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509826900&w=2

> days of Eric Youngdale I have believed that SCSI Host Bus
> Adapters (HBAs) should be addressable devices, just like
> network interfaces. IMO it is the block layer and its
> associated end devices that are the legacy thinking.

Host Adapters are addressable -- if there's an initiator
on the domain, the discover process will discover it
and it will show up in the SAS sysfs tree.

> It is ironic that as the author of the SG_IO
> passthrough ioctl the "specs" that I am
> often asked to help circumvent are the "we
> know better" variety built into various layers
> of the linux kernel :-)

Indeed.

	Luben

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

[Luben Tuikov]

On 09/29/05 20:35, Linus Torvalds wrote:
> And that's my point. Specs are not only almost invariably badly written, 
> they also never actually match reality. 

Linus, the world has changed around you.

Take a look at the SAS spec and then at a SAS chip
implementation, for example.

(We're talking abou T10 specs, right?)

> And that's way _way_ too common. People who ignore reality are sadly not 
> at all unusual.

You are saying I ignored reality?

> Talk about working code that is _readable_ and _works_.

http://linux.adaptec.com/sas/

	Luben

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

[Andre Hedrick]

On Thu, 29 Sep 2005, David S. Miller wrote:

Dave,

Thanks for filling in the details I was missing about the TOE history.

Glad to see you laugh about the ski stuff.  I thought about snowboarding
then realized I would make a great mogal for someone to do an ali off.  If
you are open to questions about TOE/RDMA stuff, would like to chat with
you and see your POV on the subject.

> In that case, it is indeed a vendor trying to shove their particular
> solution down our throats.  They never even attempt to try out the
> alternatives, and we've even gone through the trouble of coming up
> with several.  And they do this because their whole buisness model is
> all about their scheme to the exclusion of anything else, not because
> what they have is better.

Luben,

Reading Dave's points above tends to point to adaptec's current direction,
as we all know. TOEs were rejected.

I stated I would help with SAS adoption because there is a SAS-Transport
model.  I asked about a possible libadaptec + libsas, and still waiting to
see if you and adaptec are up for the task.  Right now the only path open
is the one Jeff Garzik is putting forward along with James and Christop.
I have a vested interest in seeing SAS-Transport, otherwise I would have
cut and run a long time ago.

These long email threads where everyone is shout from the top of their
hill never wins anything.  After a while the hill becomes flat (from all
the stomping), and you become old and tired.

LSI pointed out they mask there SAS in firmware and make it show up in a
scsi-like or scsi state.  They also pointed out other vendors have taken
this road.  Even if Adaptec did not go this way in hardware, there still
has to be a way to map into SCSI ... sheesh this is Adaptec known for
SCSI.

Just an FYI, would suggest you cool your heels and listen for the quiet
responses.  There is more heat than light right now; maybe this thread
will offset some of the cost in the energy criss.  Will pass on advice
handed to me (when I was a maintainer) relax and listen, nobody is out to
get you (and they were right).

Cheers,

Andre

PS I didn't listen to that advice back then, don't make the same mistake.

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

[Douglas Gilbert]

Linus Torvalds wrote:
> 
> On Thu, 29 Sep 2005, Luben Tuikov wrote:
> 
>>>   It's like real science: if you have a theory that doesn't match 
>>>   experiments, it doesn't matter _how_ much you like that theory. It's
>>>   wrong. You can use it as an approximation, but you MUST keep in mind 
>>>   that it's an approximation.
>>
>>But this is _the_ definition of a theory.  No one is arguing that
>>a theory is not an approximation to observed behaviour.
> 
> 
> No.
> 
> A scientific theory is an approximation of observed behaviour WITH NO 
> KNOWN HOLES.
> 
> Once there are known holes in the theory, it's not a scientific theory. At 
> best it's an approximation, but quite possibly it's just plain wrong.
> 
> And that's my point. Specs are not only almost invariably badly written, 
> they also never actually match reality. 
> 
> At which point at _best_ it's just an approximation. At worst, it's much 
> worse. At worst, it causes people to ignore reality, and then it becomes 
> religion.
> 
> And that's way _way_ too common. People who ignore reality are sadly not 
> at all unusual.
> 
> "But the spec says ..." is pretty much always a sign of somebody who has 
> just blocked out the fact that some device doesn't.
> 
> So don't talk about specs.

Why not?

There are good, bad and ill-timed specs. The bad ones are
ignored. Ill-timed ones gather dust, for example the
SCSI Ultra 640 standard (SPI-5) since the industry has
bet on SAS; hope they weren't expecting timely driver
support from Linux.

As for a good spec how about the Multi Media Command (MMC)
set which allows us to read music and data CDs written
almost twenty years ago plus many different formats since
then. It is currently (in MMC-5) being enhanced to cope
with the next big bun fight in that space: Blue ray and
HD-DVD (and their various content protection systems).

In the t10.org hierarchy of specs, MMC is subservient to
the primary commands (SPC) and the general architecture
(SAM). The companies that work in the MMC space (and
tend to define that standard) have "bent the rules" over
the years. The response from the (different set of)
companies that are behind SPC and SAM was to make
allowance for MMC.
The process seems to work pretty well and I am unaware
of any proposed alternate interfaces. Transports have
come and gone but the logical interface has remained.

> Talk about working code that is _readable_ and _works_.

For SAS we have a well thought out definition for what the
interface should be to hardware specific drivers IMO. It is
called CSMI, rechristened SDI. The editor of SDI is also
the editor of SAS, SAS-1.1 and SAS-2. Judging from his work,
he knows his stuff. Unfortunately SDI uses ioctls to define
its interface, which is mainly between two kernel layers
(if one ignores pass throughs). Sorry, did I mention "ioctl",
oh that makes SDI unacceptable. Almost a year ago that is what
happened to the first proposed SAS driver for Linux. That
decision has pushed Luben (amongst others) into the position
he is in now: come up with a "better" design, produce code
and then watch it get rejected. So please cut Luben a bit
of slack.

Just in case people think that I agree with Luben on using
sysfs to represent the whole SAS topology and interesting
bits suspended in it (i.e. SAS expanders), then I don't.
I am, however, prepared to argue the detail. Since the
days of Eric Youngdale I have believed that SCSI Host Bus
Adapters (HBAs) should be addressable devices, just like
network interfaces. IMO it is the block layer and its
associated end devices that are the legacy thinking.

> There's an absolutely mindbogglingly huge difference between the two.

It is ironic that as the author of the SG_IO
passthrough ioctl the "specs" that I am
often asked to help circumvent are the "we
know better" variety built into various layers
of the linux kernel :-)

Doug Gilbert

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

[Andre Hedrick]

Linus,

I have to tip my hat to you sir.

As much as I wanted to believe and tried to make it happen ... ATA/IDE was
forced to design many exception case events.  Regardless how hard I an
others tried to invoke/create a driver to mimic the "SPEC", the hardware
people broke most of the rules and each chipset was littered with
exception cases.

It has been 7 years since you and I started butting heads, and in the end
both of us were right.  A driver could be written to follow the standard
exactly, and it would never work (alone, as-is) because the hardware was
not paying attention the rules book.

Hope you can kick back and laugh about the history, too!

Have a great Day!

Andre Hedrick
LAD Storage Consulting Group

On Thu, 29 Sep 2005, Linus Torvalds wrote:

> 
> 
> On Thu, 29 Sep 2005, Arjan van de Ven wrote:
> > 
> > a spec describes how the hw works... how we do the sw piece is up to
> > us ;)
> 
> How we do the SW is indeed up to us, but I want to step in on your first 
> point.
> 
> Again.
> 
> A "spec" is close to useless. I have _never_ seen a spec that was both big 
> enough to be useful _and_ accurate.
> 
> And I have seen _lots_ of total crap work that was based on specs. It's 
> _the_ single worst way to write software, because it by definition means 
> that the software was written to match theory, not reality.
> 
> So there's two MAJOR reasons to avoid specs:
> 
>  - they're dangerously wrong. Reality is different, and anybody who thinks 
>    specs matter over reality should get out of kernel programming NOW. 
>    When reality and specs clash, the spec has zero meaning. Zilch. Nada.
>    None.
> 
>    It's like real science: if you have a theory that doesn't match 
>    experiments, it doesn't matter _how_ much you like that theory. It's
>    wrong. You can use it as an approximation, but you MUST keep in mind 
>    that it's an approximation.
> 
>  - specs have an inevitably tendency to try to introduce abstractions
>    levels and wording and documentation policies that make sense for a 
>    written spec. Trying to implement actual code off the spec leads to the 
>    code looking and working like CRAP. 
> 
>    The classic example of this is the OSI network model protocols. Classic 
>    spec-design, which had absolutely _zero_ relevance for the real world. 
>    We still talk about the seven layers model, because it's a convenient 
>    model for _discussion_, but that has absolutely zero to do with any 
>    real-life software engineering. In other words, it's a way to _talk_ 
>    about things, not to implement them.
> 
>    And that's important. Specs are a basis for _talking_about_ things. But 
>    they are _not_ a basis for implementing software.
> 
> So please don't bother talking about specs. Real standards grow up 
> _despite_ specs, not thanks to them.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Andre Hedrick]

Prasenjit,

The role of a standards body is to self promote and backslap each other
amd figure out how to divide the market and make money and not cause
problems.

The problem here is T10/T11 is the protocol is "ends justify the means".

This is where the clash of technical and design happens.

If the standards body was going to "primarily enforce interoperability",
then why the heck did the T10 proposal for "domain validation" become an
empty file and was withdrawn?  IIRC it was Adaptec who helped to kill
Domain Validation on T10, but I could be wrong and correction is warrented
here if needed.

"(iv) none of them come close to the T10 FSMs" is the answer, and this
justifies Linux's position to operate under "ends justify the means".

I can tell you why the T13 proposal died.  I killed when I withdrew it as
a direct result of T10's actions or lack of such.

As much as I believe in NCITS standards, they are worthless if no one is
there to assist in the process of creation, model, and adoption.

Regardless of anything stated above, the problem with creation of a scsi
standard core is most of the VOODOO of SCSI is hidden in the firmware.
James knows this fact and points it out on occassion.  SCSI is a FUZZY
State Machine and nowhere close to being consider finite.

Not sure if there is a good solution to date; however, James does have an
strong understanding of the mess and Christop is a good right hand
enforcer regardless that he and I disagree more often than agree.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 29 Sep 2005, Prasenjit Sarkar wrote:

> Luben,
> 
> The role of standard bodies is to primarily enforce interoperability but
> while they suggest FSMs and layering, those directives are not mandatory.
> 
> I have also seen industrial SCSI Core implementations from various sources
> to come to the following conclusions (i) they do not implement all the
> manadatory stuff (ii) they implement just enough to get by with
> interoperability [who has the time] (iii) any layering design is
> evolutionary and (iv) none of them come close to the T10 FSMs.
> 
> You may disagree, but there needs to be a balance between standards and
> implementations.
> 
> 
> 
> 
>                                                                            
>              Luben Tuikov                                                  
>              <ltuikov@yahoo.co                                             
>              m>                                                         To 
>              Sent by:                  Linus Torvalds <torvalds@osdl.org>, 
>              linux-scsi-owner@         Arjan van de Ven                    
>              vger.kernel.org           <arjan@infradead.org>               
>                                                                         cc 
>                                        Willy Tarreau <willy@w.ods.org>,    
>              09/29/2005 04:20          SCSI Mailing List                   
>              PM                        <linux-scsi@vger.kernel.org>,       
>                                        Andrew Morton <akpm@osdl.org>,      
>                                        Linux Kernel Mailing List           
>              Please respond to         <linux-kernel@vger.kernel.org>,     
>              ltuikov@yahoo.com         Luben Tuikov                        
>                                        <luben_tuikov@adaptec.com>, Jeff    
>                                        Garzik <jgarzik@pobox.com>          
>                                                                    Subject 
>                                        Re: I request inclusion of SAS      
>                                        Transport Layer and AIC-94xx into   
>                                        the kernel                          
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
> 
> 
> 
> 
> --- Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > A "spec" is close to useless. I have _never_ seen a spec that was both
> big
> > enough to be useful _and_ accurate.
> >
> > And I have seen _lots_ of total crap work that was based on specs. It's
> > _the_ single worst way to write software, because it by definition means
> > that the software was written to match theory, not reality.
> 
> A spec defines how a protocol works and behaves.  All SCSI specs
> are currently very layered and defined by FSMs.
> 
> This is _the reason_ I can plug in an Adaptec SAS host adapter
> to Vitesse Expander which has a Seagate SAS disk attached to phy X...
> And guess what? They interoperate and communicate with each other.
> 
> Why?  Because at each layer (physical/link/phy/etc) each
> one of them follow the FSMs defined in the, guess where, SAS spec.
> 
> If you take a SAS/SATA/FC/etc course, they _show you_ a link
> trace and then _show_ you how all of it is defined by the FSM
> specs, and make you follow the FSMs.
> 
> > So there's two MAJOR reasons to avoid specs:
> 
> Ok, then I accept that you and James Bottomley and Christoph are
> _right_, and I'm wrong.
> 
> I see we differ in ideology.
> 
> >    It's like real science: if you have a theory that doesn't match
> >    experiments, it doesn't matter _how_ much you like that theory. It's
> >    wrong. You can use it as an approximation, but you MUST keep in mind
> >    that it's an approximation.
> 
> But this is _the_ definition of a theory.  No one is arguing that
> a theory is not an approximation to observed behaviour.
> 
> What you have here is interoperability. Only possible because
> different vendors follow the same spec(s).
> 
> >  - specs have an inevitably tendency to try to introduce abstractions
> >    levels and wording and documentation policies that make sense for a
> >    written spec. Trying to implement actual code off the spec leads to
> the
> >    code looking and working like CRAP.
> 
> Ok, I give up: I'm wrong and you and James B are right.
> 
> >    The classic example of this is the OSI network model protocols.
> Classic
> 
> Yes, it is a _classic_ example and OSI is _very_ old.
> 
> _But_ the tendency of representing things in a _layered_, object oriented
> design has persisted.
> 
> >    spec-design, which had absolutely _zero_ relevance for the real world.
> 
> >    We still talk about the seven layers model, because it's a convenient
> >    model for _discussion_, but that has absolutely zero to do with any
> >    real-life software engineering. In other words, it's a way to _talk_
> >    about things, not to implement them.
> 
> Ok.
> 
> >    And that's important. Specs are a basis for _talking_about_ things.
> But
> >    they are _not_ a basis for implementing software.
> 
> Ok.  Let's forget about maintenance and adding _new_ functionality.
> 
> > So please don't bother talking about specs. Real standards grow up
> > _despite_ specs, not thanks to them.
> 
> Yes, you're right. Linus is always right.
> 
> Now to things more pertinent, which I'm sure people are interested in:
> 
> Jeff has been appointed to the role of integrating the SAS code
> with the Linux SCSI _model_, with James Bottomley's "transport attributes".
> So you can expect more patches from him.
> 
> Regards,
>     Luben
> 
> P.S. I have to get this 8139too.c network card here working.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Theodore Ts'o]

On Thu, Sep 29, 2005 at 04:20:13PM -0700, Luben Tuikov wrote:
>
> A spec defines how a protocol works and behaves.  All SCSI specs
> are currently very layered and defined by FSMs.

A spec defines how a protocol works and behaves --- *if* it is
well-specified and unambiguous, and *if* vendors actually implement
the spec correctly.  (And sometimes vendors have major economic
incentives to cheat and either intentionally violate the
specification, or simply not bother to test to make sure whether or
not they implemented their hardware correctly.)

Computing history has been literred with specifications that were
incompentently written and/or incompentently implemented --- from the
disaster known as ACPI, to FDDI (early FDDI networking gear was
interoperable only if you bought all of your gear from one vendor,
natch), consumer-grade disks which lied about when data had been
safely written to iron oxide to garner better Winbench scores, and
many, many, many others.

This is one of the reasons why the IETF doesn't bless a networking
standard until there are multiple independent, interoperable
implementations --- and even _then_ there will be edge cases that
won't be caught until much, much later.

In those cases, if you implement something which is religiously
adherent to the specification, and it doesn't interoperate with the
real world (i.e., everybody else, or some large part of the industry)
--- do you claim that you are right because you are following the
specification, and everyone else in the world is wrong?  Or do you
adapt to reality?  People who are too in love with specifications so
that they are not willing to be flexible will generally not be able to
achieve complete interoperability.  This is the reason for the IETF
Maxim --- be conservative in what you send, liberal in what you will
accept.  And it's why interoperability testing and reference
implementations are critical.

But it's also important to remember when there is a reference
implementation, or pseudo-code in the specification, it's not the only
way you can implement things.  Very often, as Linus has pointed out,
there are reasons why the pseudo-code in the specification is wholely
inappropriate for a particular implementation.  But that's OK; the
implementation can use a different implementastion, as long as the
result is interoperable.

Regards,

						- Ted

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

[Marcin Dalecki]

On 2005-09-30, at 02:35, Linus Torvalds wrote:
>
> No.
>
> A scientific theory is an approximation of observed behaviour WITH NO
> KNOWN HOLES.

Since "approximation" is equivalent to a "known hole", there is no  
single scientific theory without known holes out there?! Well that's  
a segfault in brain - unless you don't consider math science of course.

A scientific theory is just a set of axioms and deduction rules. Not  
much more by definition...

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

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Wed, 28 Sep 2005, Matthew Wilcox wrote:
>> 
>> Dude, that document is written in a very tongue-in-cheek style.
>
> True, true. But sometimes you can say painful truths more easily if you do 
> it as a joke. Most of the ManagementStyle document is perfectly valid.

Yes, I thought I understood it when I read it first, but I later
realized that my understanding was very superficial.

When I re-read it now, I cannot help chuckling, remembering how
you kept saying "go wild", "make it so", "That is good, but it
strikes me that there is no fundamental reason to limit
ourselves to ..."  on the git list ;-).

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

[Martin Fouts]

Warning: philosophical thread hijack ahead ;) 

> A scientific theory is an approximation of observed behaviour 
> WITH NO KNOWN HOLES.

This has nothing to do with the topic at hand, but it is a pet peeve of
mine.  Sorry for hijacking a thread.

The above is a good one sentence approximation of what a theory is in
science, but it's not correct.  The classic example, of course, is
quantum mechanics, which is a very good theory, and has the glaring
notorious hole of lacking an explanation for gravity.

> 
> Once there are known holes in the theory, it's not a 
> scientific theory. At best it's an approximation, but quite 
> possibly it's just plain wrong.
> 

Alas, the difference between theory and practice is much larger in
practice.  Most scientific theories have known holes in them.  Not
always as glaring as the lack of quantum gravity, but always present.

There are even well documented cases where the theory was not supported
by the observations, so the observations were, eventually, redone, only
to determine that they were done wrong in the first place; so it's not
even as simple as 'must agree with reality'.

Science, once you lift the lid is a very messy endevour.

> And that's my point. Specs are not only almost invariably 
> badly written, they also never actually match reality. 

Ooops.  I'm going to have to go back on topic here.  I think that a
large part of this debate over specs is due to looking at two different
aspects of specs.  I have often worked in a world where specs were very
accurate, and kept current with reality.  This is the world in which
specs are the basis for new things.  When it works, it works very well.

Most of us, though, are living in the world of finished devices.  The
problem in our world is that specs are allowed to bit-rot.  Architects,
when they care a lot about their work, maintain two sets of plans, the
'as designed' plans and the  'as built' plans.  We in the computer
industry, for a lot of reasons, tend not to maintain the 'as built'
plans.

> So don't talk about specs.

Unfortunately, even in our imperfect world of imperfect specs, we still
need them.  Rather than 'don't talk about specs', in the real world, we
have to deal with 'here's a spec, add a grain of salt'.  You don't get
interoperability without that, and you don't get code portability
without it either.

> 
> Talk about working code that is _readable_ and _works_.
> 

Once upon a time, we converted an (unnamed) fortune 500 company's C
compiler from vendor X to vendor Y.  As head of the OS team, I
volunteered our kernel as a test ap.  Eventually, we found a very
readable implementation of select that, unfortunately, was utterly
busted C code.  "luckily", the old compiler had a bug in it that caused
it to generate working code for the utterly busted C code.

Needless to say that reality and the spec differed in this case.

And we fixed reality to match the spec.

> There's an absolutely mindbogglingly huge difference between the two.
> 

Yes.  "Be pragmatic about specs" is very good advice.  "Ignore specs" is
a recipe for anarchy. ;)

We now return your thread to its regularly scheduled debate.

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

[Hua Zhong]

> Once there are known holes in the theory, it's not a
> scientific theory. At best it's an approximation, but
> quite possibly it's just plain wrong.

You are right about scientific theory, but specs are not just a theory.
You are mixing "discovery" and "invention".

A scientific theory has to match reality, because the universe deveops
independently. There is no way you can enforce your theory down the
throat on the "nature".

But the roles of specs are more than that. There are two parts of it:
1. unify/summarize the reality
2. guide future implementations on a unified road

It might do job 1 poorly (simply because the reality is a mess),
but if everyone from the point on puts the effort to follow it, job 2 can
be done, and it is the real goal. It can do this simply because *humans*
can collaborate and be influenced for a goal that could eventually
benefit everybody.

> And that's my point. Specs are not only almost invariably
> badly written, they also never actually match reality.
>
> At which point at _best_ it's just an approximation. At
> worst, it's much worse. At worst, it causes people to
> ignore reality, and then it becomes religion.

Let me add more to the moron/asshole argument:

Anyone that thinks specs are reality is a moron.

Anyone that thinks specs are useless and refuses to collaborate
is an asshole. :)

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

[Linus Torvalds]

On Thu, 29 Sep 2005, Luben Tuikov wrote:
>
> >    It's like real science: if you have a theory that doesn't match 
> >    experiments, it doesn't matter _how_ much you like that theory. It's
> >    wrong. You can use it as an approximation, but you MUST keep in mind 
> >    that it's an approximation.
> 
> But this is _the_ definition of a theory.  No one is arguing that
> a theory is not an approximation to observed behaviour.

No.

A scientific theory is an approximation of observed behaviour WITH NO 
KNOWN HOLES.

Once there are known holes in the theory, it's not a scientific theory. At 
best it's an approximation, but quite possibly it's just plain wrong.

And that's my point. Specs are not only almost invariably badly written, 
they also never actually match reality. 

At which point at _best_ it's just an approximation. At worst, it's much 
worse. At worst, it causes people to ignore reality, and then it becomes 
religion.

And that's way _way_ too common. People who ignore reality are sadly not 
at all unusual.

"But the spec says ..." is pretty much always a sign of somebody who has 
just blocked out the fact that some device doesn't.

So don't talk about specs.

Talk about working code that is _readable_ and _works_.

There's an absolutely mindbogglingly huge difference between the two.

			Linus

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

[Prasenjit Sarkar]

Luben,

The role of standard bodies is to primarily enforce interoperability but
while they suggest FSMs and layering, those directives are not mandatory.

I have also seen industrial SCSI Core implementations from various sources
to come to the following conclusions (i) they do not implement all the
manadatory stuff (ii) they implement just enough to get by with
interoperability [who has the time] (iii) any layering design is
evolutionary and (iv) none of them come close to the T10 FSMs.

You may disagree, but there needs to be a balance between standards and
implementations.




                                                                           
             Luben Tuikov                                                  
             <ltuikov@yahoo.co                                             
             m>                                                         To 
             Sent by:                  Linus Torvalds <torvalds@osdl.org>, 
             linux-scsi-owner@         Arjan van de Ven                    
             vger.kernel.org           <arjan@infradead.org>               
                                                                        cc 
                                       Willy Tarreau <willy@w.ods.org>,    
             09/29/2005 04:20          SCSI Mailing List                   
             PM                        <linux-scsi@vger.kernel.org>,       
                                       Andrew Morton <akpm@osdl.org>,      
                                       Linux Kernel Mailing List           
             Please respond to         <linux-kernel@vger.kernel.org>,     
             ltuikov@yahoo.com         Luben Tuikov                        
                                       <luben_tuikov@adaptec.com>, Jeff    
                                       Garzik <jgarzik@pobox.com>          
                                                                   Subject 
                                       Re: I request inclusion of SAS      
                                       Transport Layer and AIC-94xx into   
                                       the kernel                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




--- Linus Torvalds <torvalds@osdl.org> wrote:
>
> A "spec" is close to useless. I have _never_ seen a spec that was both
big
> enough to be useful _and_ accurate.
>
> And I have seen _lots_ of total crap work that was based on specs. It's
> _the_ single worst way to write software, because it by definition means
> that the software was written to match theory, not reality.

A spec defines how a protocol works and behaves.  All SCSI specs
are currently very layered and defined by FSMs.

This is _the reason_ I can plug in an Adaptec SAS host adapter
to Vitesse Expander which has a Seagate SAS disk attached to phy X...
And guess what? They interoperate and communicate with each other.

Why?  Because at each layer (physical/link/phy/etc) each
one of them follow the FSMs defined in the, guess where, SAS spec.

If you take a SAS/SATA/FC/etc course, they _show you_ a link
trace and then _show_ you how all of it is defined by the FSM
specs, and make you follow the FSMs.

> So there's two MAJOR reasons to avoid specs:

Ok, then I accept that you and James Bottomley and Christoph are
_right_, and I'm wrong.

I see we differ in ideology.

>    It's like real science: if you have a theory that doesn't match
>    experiments, it doesn't matter _how_ much you like that theory. It's
>    wrong. You can use it as an approximation, but you MUST keep in mind
>    that it's an approximation.

But this is _the_ definition of a theory.  No one is arguing that
a theory is not an approximation to observed behaviour.

What you have here is interoperability. Only possible because
different vendors follow the same spec(s).

>  - specs have an inevitably tendency to try to introduce abstractions
>    levels and wording and documentation policies that make sense for a
>    written spec. Trying to implement actual code off the spec leads to
the
>    code looking and working like CRAP.

Ok, I give up: I'm wrong and you and James B are right.

>    The classic example of this is the OSI network model protocols.
Classic

Yes, it is a _classic_ example and OSI is _very_ old.

_But_ the tendency of representing things in a _layered_, object oriented
design has persisted.

>    spec-design, which had absolutely _zero_ relevance for the real world.

>    We still talk about the seven layers model, because it's a convenient
>    model for _discussion_, but that has absolutely zero to do with any
>    real-life software engineering. In other words, it's a way to _talk_
>    about things, not to implement them.

Ok.

>    And that's important. Specs are a basis for _talking_about_ things.
But
>    they are _not_ a basis for implementing software.

Ok.  Let's forget about maintenance and adding _new_ functionality.

> So please don't bother talking about specs. Real standards grow up
> _despite_ specs, not thanks to them.

Yes, you're right. Linus is always right.

Now to things more pertinent, which I'm sure people are interested in:

Jeff has been appointed to the role of integrating the SAS code
with the Linux SCSI _model_, with James Bottomley's "transport attributes".
So you can expect more patches from him.

Regards,
    Luben

P.S. I have to get this 8139too.c network card here working.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Luben Tuikov]

--- Linus Torvalds <torvalds@osdl.org> wrote:
> 
> A "spec" is close to useless. I have _never_ seen a spec that was both big 
> enough to be useful _and_ accurate.
> 
> And I have seen _lots_ of total crap work that was based on specs. It's 
> _the_ single worst way to write software, because it by definition means 
> that the software was written to match theory, not reality.

A spec defines how a protocol works and behaves.  All SCSI specs
are currently very layered and defined by FSMs.

This is _the reason_ I can plug in an Adaptec SAS host adapter
to Vitesse Expander which has a Seagate SAS disk attached to phy X...
And guess what? They interoperate and communicate with each other.

Why?  Because at each layer (physical/link/phy/etc) each
one of them follow the FSMs defined in the, guess where, SAS spec.

If you take a SAS/SATA/FC/etc course, they _show you_ a link
trace and then _show_ you how all of it is defined by the FSM
specs, and make you follow the FSMs.

> So there's two MAJOR reasons to avoid specs:

Ok, then I accept that you and James Bottomley and Christoph are
_right_, and I'm wrong.

I see we differ in ideology.

>    It's like real science: if you have a theory that doesn't match 
>    experiments, it doesn't matter _how_ much you like that theory. It's
>    wrong. You can use it as an approximation, but you MUST keep in mind 
>    that it's an approximation.

But this is _the_ definition of a theory.  No one is arguing that
a theory is not an approximation to observed behaviour.

What you have here is interoperability. Only possible because
different vendors follow the same spec(s).

>  - specs have an inevitably tendency to try to introduce abstractions
>    levels and wording and documentation policies that make sense for a 
>    written spec. Trying to implement actual code off the spec leads to the 
>    code looking and working like CRAP. 

Ok, I give up: I'm wrong and you and James B are right.

>    The classic example of this is the OSI network model protocols. Classic 

Yes, it is a _classic_ example and OSI is _very_ old.

_But_ the tendency of representing things in a _layered_, object oriented
design has persisted.

>    spec-design, which had absolutely _zero_ relevance for the real world. 
>    We still talk about the seven layers model, because it's a convenient 
>    model for _discussion_, but that has absolutely zero to do with any 
>    real-life software engineering. In other words, it's a way to _talk_ 
>    about things, not to implement them.

Ok.
 
>    And that's important. Specs are a basis for _talking_about_ things. But 
>    they are _not_ a basis for implementing software.

Ok.  Let's forget about maintenance and adding _new_ functionality.
 
> So please don't bother talking about specs. Real standards grow up 
> _despite_ specs, not thanks to them.

Yes, you're right. Linus is always right.

Now to things more pertinent, which I'm sure people are interested in:

Jeff has been appointed to the role of integrating the SAS code
with the Linux SCSI _model_, with James Bottomley's "transport attributes".
So you can expect more patches from him.

Regards,
    Luben

P.S. I have to get this 8139too.c network card here working.

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

[jerome lacoste]

<fun_but_off_topic>

[Removing most of the CC. Because they've got real work to do]

On 9/29/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
[...]

> A "spec" is close to useless.

The only usefulness of a spec is to allow to differ between morons and assholes.

http://diveintomark.org/archives/2004/08/16/specs

Couldn't resist.

</fun_but_off_topic>

J

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

[Joel Becker]

On Thu, Sep 29, 2005 at 02:39:44PM -0400, Luben Tuikov wrote:
> So you see, it is _not_ about accepting code, it is about
> accepting _ideas_ and _innovation_.
> 
> James can still do everything _his_ way.  The question is
> how many _years_ would this be relevant?

	Is your cat sleeping on your underscore key?

Joel

-- 

"There is no more evil thing on earth than race prejudice, none at 
 all.  I write deliberately -- it is the worst single thing in life 
 now.  It justifies and holds together more baseness, cruelty and
 abomination than any other sort of error in the world." 
        - H. G. Wells

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

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

[Luben Tuikov]

--- Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Luben Tuikov wrote:
> > What you'll see in the code is:
> > 
> >   hardware implementation  (interconnect, SAM 4.15, 1.3)
> >       firmware implementation  (interconnect, SDS, SAM 4.6, 1.3)
> >           LLDD                     (SAM, section 5, 6, 7)
> >              Transport Layer          (SAM 4.15, SAS)
> >                   SCSI Core             (SAM section 4,5,8)
> >                      Commmand Sets        (SAM section 1)
> > 
> > A very nice explanation in latest SAM4r03,
> > section 4.15 The SCSI model for distributed communications.
> 
> BTW, Linux' implementations of transports like USB storage and SBP-2 
> have always been similarly layered. (Actually they come with at least 
> one more layer between LLDD and SCSI core.) Needless to say that these 
> transports need their specific managing infrastructures. So this 
> layering is not at all new to Linux.

True, true.

But those subsystems are shielded from SCSI Core.  Plus SCSI Core
is managed by people unaware of SAM or the layering infrastructure.

    Luben
 
> > Now for MPT based solutions you have:
> > 
> >   LLDD                  (SAM, section 5, 6, 7)
> >      SCSI Core             (SAM section 4,5,8)
> >         Commmand Sets         (SAM section 1)
> > 
> > You see?  No Transport Layer between LLDD and SCSI Core!
> > Why?  Because all this work is done in FIRMWARE!
> 
> -- 
> Stefan Richter
> -=====-=-=-= =--= ===-=
> http://arcgraph.de/sr/
> 

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

[Stefan Richter]

Jeff Garzik wrote:
[...]
> HCIL stuff to move to SPI-specific transport code.
> 
> That is the task that must be completed BEFORE transport layer for SAS 
> can be fully merged.

So it could at least be _halfway_ merged, like it was done with the 
other non-SPI transport layers long ago, couldn't it?
-- 
Stefan Richter
-=====-=-=-= =--= ===-=
http://arcgraph.de/sr/

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

[Linus Torvalds]

On Thu, 29 Sep 2005, Arjan van de Ven wrote:
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

How we do the SW is indeed up to us, but I want to step in on your first 
point.

Again.

A "spec" is close to useless. I have _never_ seen a spec that was both big 
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's 
_the_ single worst way to write software, because it by definition means 
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

 - they're dangerously wrong. Reality is different, and anybody who thinks 
   specs matter over reality should get out of kernel programming NOW. 
   When reality and specs clash, the spec has zero meaning. Zilch. Nada.
   None.

   It's like real science: if you have a theory that doesn't match 
   experiments, it doesn't matter _how_ much you like that theory. It's
   wrong. You can use it as an approximation, but you MUST keep in mind 
   that it's an approximation.

 - specs have an inevitably tendency to try to introduce abstractions
   levels and wording and documentation policies that make sense for a 
   written spec. Trying to implement actual code off the spec leads to the 
   code looking and working like CRAP. 

   The classic example of this is the OSI network model protocols. Classic 
   spec-design, which had absolutely _zero_ relevance for the real world. 
   We still talk about the seven layers model, because it's a convenient 
   model for _discussion_, but that has absolutely zero to do with any 
   real-life software engineering. In other words, it's a way to _talk_ 
   about things, not to implement them.

   And that's important. Specs are a basis for _talking_about_ things. But 
   they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up 
_despite_ specs, not thanks to them.

		Linus

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

[Stefan Richter]

Jeff Garzik wrote:
>> The sad truth is that SCSI Core knows only HCIL.
> 
> That's something that needs fixing, for SAS.

Not just for SAS.

>> The code doesn't alter Linux SCSI or anyone else's behaviour.
>> It only _provides_ SAS support to the kernel.
> 
> That's one of the problems: It should update the SCSI core.

Sure, but the same is true for the other transports except for SPI.
-- 
Stefan Richter
-=====-=-=-= =--= ===-=
http://arcgraph.de/sr/

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

[Willy Tarreau]

On Thu, Sep 29, 2005 at 09:44:08AM +0200, Arjan van de Ven wrote:
> On Thu, 2005-09-29 at 06:04 +0200, Willy Tarreau wrote:
> > On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
> > > Linux is about getting things done, not being religious about 
> > > specifications.  You are way too focused on the SCSI specs, and missing 
> > > the path we need to take to achieve additional flexibility.
> > > 
> > > With Linux, it's all about evolution and the path we take.
> > 
> > Hmmm... I'm fine with "not being religious about specs", but I hope we
> > try to respect them as much as possible
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

No Arjan, you cannot say that ! (well, of course you can but in this case
you may be wrong). A spec describes any process, whether it's soft or hard,
and BTW, the frontier between soft and hard is diminishing. When I designed
a PI-Bus-PCI bridge 10 years ago, I used PCI 2.1 Specification. And it was
more related to software than hardware (FSMs, config registers, etc...).

It's the *implementation* which is up to us, not the spec. A spec will never
tell you that you have to be compliant with 4k stacks or things like this.
This is implementation. What it tells you is when interrupt X strikes and
you read bit Y from reg Z, then you must reset bit Y before leaving. And this
is software specs, not hardware.

> (I know the scsi stuff also provides sort of a reference "here is how
> you can do it in sw" but I see that more as you "you need this
> functionality" not "you need this exact architecture in your software")

Keeping close to an accepted standard model makes it far easier to upgrade
later, but you're right, the spec does not tell you what your implementation
must look like.

I think we agree but just don't give the exact same meaning to words.

Regards,
Willy

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

[Stefan Richter]

Jeff Garzik wrote:
> * Avoids (rather than fix) several SCSI core false dependencies on HCIL. 

BTW, other SCSI transport layers in Linux do this too, and have been 
doing so for some time. So this is hardly a valid reason not to include 
the new SAS layer.
-- 
Stefan Richter
-=====-=-=-= =--= ===-=
http://arcgraph.de/sr/

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

[Bruce Ferrell]

Well said John!

For that matter get us a driver for the embedded 7902 (is that the one? 
  I forget now) with host raid support.



John Stoffel wrote:
> Luben,
> 
> I'd really prefer if you'd just stop on your tirade and just send in a
> 10 line patch for the existing linux SCSI subsystem to fix something
> you think is wrong. 
> 
> Code talks, bullshit walks.  
> 
> Sure, Linux SCSI might not be ideal, but how many people do you know
> have SAS storage on their home PCs right now?  Heck, I don't have SATA
> or PIV on my home system!  
> 
> And as a customer of Adaptec hardware, I'm getting to the point of
> seriously taking my money and going elsewhere for my storage needs.
> If you are a general example of how Adaptec works with its customers,
> then I want nothing to do with you or your products.  
> 
> Sure, I know you think Linux is stuck in the past, so help us move to
> the future in small baby steps.  It doesn't require big huge leaps
> like you're proposing.  I mean, have you actually tried to your old
> legacy SCSI controllers in a system with your new hardware?  How did
> your testing go?  
> 
> Now I'm not a programmer, and I can't talk like one, but in my real
> life job I'm a SysAdmin and knowing what I know about Adaptec's
> interactions on this list will certainly color my perceptions of your
> hardware and trying to make it work with my company.
> 
> John
> -
> 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/
> 

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

[Stefan Richter]

Luben Tuikov wrote:
> On 09/28/05 18:43, Andre Hedrick wrote:
>>Have you and company considered the approach of mapping to a library of
>>sorts?
> 
> Hmm, it is not a library.
> 
> It is a layer, again, because of what the chip actually is, and because
> of what it implements.
> 
> Take a look at the announcement text, I do give some description there
> and in the code the drivers/scsi/sas-class/README file describes
> the event/managment infrastructure.  Also you can take a look at the code.
> http://linux.adaptec.com/sas/
> 
> What you'll see in the code is:
> 
>   hardware implementation  (interconnect, SAM 4.15, 1.3)
>       firmware implementation  (interconnect, SDS, SAM 4.6, 1.3)
>           LLDD                     (SAM, section 5, 6, 7)
>              Transport Layer          (SAM 4.15, SAS)
>                   SCSI Core             (SAM section 4,5,8)
>                      Commmand Sets        (SAM section 1)
> 
> A very nice explanation in latest SAM4r03,
> section 4.15 The SCSI model for distributed communications.

BTW, Linux' implementations of transports like USB storage and SBP-2 
have always been similarly layered. (Actually they come with at least 
one more layer between LLDD and SCSI core.) Needless to say that these 
transports need their specific managing infrastructures. So this 
layering is not at all new to Linux.

> Now for MPT based solutions you have:
> 
>   LLDD                  (SAM, section 5, 6, 7)
>      SCSI Core             (SAM section 4,5,8)
>         Commmand Sets         (SAM section 1)
> 
> You see?  No Transport Layer between LLDD and SCSI Core!
> Why?  Because all this work is done in FIRMWARE!

-- 
Stefan Richter
-=====-=-=-= =--= ===-=
http://arcgraph.de/sr/

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

[Luben Tuikov]

On 09/29/05 13:13, Bernd Petrovitsch wrote:
> different opinions about "quality" and/or "correct vs wrong" - I can't
> decide since I have virtually no knowledge about SCSI core internals,

Ok.

> discussions on the Linux-SCSI-ML, etc. to decide - not even for me -,
> who is "right" and/or "wrong" in which aspect or in general), it comes
> down to "better the not-so-good design and working code than the best
> design and no code".

That sounds very fine, _but_ "the community" isn't a "corporation".

"The community" is by far and wide very close friends, so if you
point out to one of them that his code is wrong, even if all
other see that you're indeed correct, no one would say anything.

Why?  Because he doesn't want to same thing done to him.

So it doesn't matter who is right or who is wrong.  What matters
is who has political power to have it his way.

> So just copy the old core, throw out what you don't want, need and/or
> like and voila. If it *is* "better", it will succeed and people will
> come and help.

Blesses art thou, who believeth.

I wish it worked like this, I really wished.  Sadly its doesn'
work like this.

James is a strong political figure.  He keeps people who he thinks
know more than him at bay.  I can quote several names here, who
are active and some who were active at one point or another,
all very well versed in the T10 ways, but it wouldn't be fare to them.

So what you have is a strong political game: they don't care
what is right or wrong, they'll implement it the way _they_ think
is right, in effect alongside _their_ code.

I'm not sure how much History the readers have studied, but such
politics have always yielded to extinction.

The reason is _not_ because you reject something, but because
you end up always doing it always _your_ way.  Eventually you
become unfit to compete when the world has changed _so much_
around you, that "your way" is no longer relevant and the change
to make you fit is so radical, that it is impossible to do.

So you see, it is _not_ about accepting code, it is about
accepting _ideas_ and _innovation_.

James can still do everything _his_ way.  The question is
how many _years_ would this be relevant?

> [0]: Not in the ironic interpretation in German which translates roughly
>      to "great, another one does it".

Yes, but in "the community" people want "great, he does it _my_ way".

	Luben

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

[Luben Tuikov]

On 09/29/05 12:54, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>of SAS.  THE REASON THEY WERE INTRODUCED INTO LINUX BY JB IS TO
>>ACCOMODATE MPT-based SOLUTIONS FROM TWIDDLING WITH IOCTLS!
> 
> 
> Wrong.  This shows you fundamentally don't understand transport classes 
> at all.
> 
> AFAIK, the first transport class was FC, for qla2xxx.
> 
> Read the code to see how FC avoids the SPI-centric scan -- an example of 
> transport independence.

And it shows that you do not understand SAM.

How do I know this: simple: JB's "transport attributes" have
NOTHING to do with SAM.

They break the layering architecture for one, and are
ATTRIBUTE EXPORTING FACILITY for another.

I understand that you want to preserve your friend's
bal^w^w^wpride but, lets face it:
  I do not try to shove my solution down JB's throat.

As I've said many times: they are different due to
the *technology they represent*, which differs in
implmentation, and they can coexist!

If you can say this statement:
  "The core problem is that a SAM-friendly path to SAS
   has already been chosen -- transport classes -- and
   your driver isn't following this path."

This means that you have NO CLUE ABOUT SAS or SAM!

I certainly hope that things would improve once you
start reading specs and talking to the engineers
who designed BCM8603.  (If you are still going to
write their driver for them.)

>>How do I know this: simple: JB's "transport attributes" have
>>NOTHING to do with SAM.
>>
>>They break the layering architecture for one, and are
>>ATTRIBUTE EXPORTING FACILITY for another.
> 
> 
> Transport class == transport layer.  Eventually this will sink in.
> 
> Transport class allows for complete transport independence, be it SAS, 
> FC, iSCSI, or other.

Nah -- all FUD.

See how you're talking general stuff.  See how I talk
specifics:

The host template was introduced to satisfy SPI only
LLDD which was everything available at that time and
SAM didn't exist yet.

Over time it was enlarged to accomodate others and
all LLDD implemented it and simulated SPI centric
view.

Now, you have a storage chip on a pci device which is
NOT a host template material.

I.e. the LLDD is a _PCI_ device driver, NOT SCSI!

It exports only a SAM section 5, 6 and 7 view of
the Service Delivery Subsystem and interconnect.

It does _not_ export anything "scsi host" like.

For this reason you _need_ a management layer
on top, but _below_ SCSI Core, since that management
layer is _transport_ specific _and_ SCSI Core
should be completely _unaware_ of the transport!

Then _this_ transport layer, presents things
to the SCSI Core as "scsi host" material.

Among the many, lets take for example this
member of the struct scsi_host_template
along with the comment:

	/*
	 * In many instances, especially where disconnect / reconnect are
	 * supported, our host also has an ID on the SCSI bus.  If this is
	 * the case, then it must be reserved.  Please set this_id to -1 if
	 * your setup is in single initiator mode, and the host lacks an
	 * ID.
	 */
	int this_id;

SPI-centric?

How about this from scsi_host:

	/*
	 * These three parameters can be used to allow for wide scsi,
	 * and for host adapters that support multiple busses
	 * The first two should be set to 1 more than the actual max id
	 * or lun (i.e. 8 for normal systems).
	 */
	unsigned int max_id;
	unsigned int max_lun;
	unsigned int max_channel;

And I can continue to give examples of this for as many lines
are in the header files of Linux SCSI.

Now Jeff will say: "Then submit patches to fix this."

> I'm merely stating I'm submitting patches to clean up SCSI core.  Others 
> have submitted far more patches than I.  And further patches to SCSI 

I've also submitted patches to improve SCSI Core.  Those improvements
came directly from my own mini-SCSI Core implementation of iSCSI Target.
For example, using the slab cache for scsi commands.

Thanks to Doug L, and Andi K, they made it in, if it had been left
to James Bottomley, they'd never be in.

Then I continued to post RFCs and various other suggestions, like
64 bit LUN, elimination of HCIL -- all shot down by your friends
in the community.

This was back when you had just started working on libata.

So please spare me the political sap -- I've tears in my eyes already.

> core are needed to properly integrate SAS as a transport completely 

Stop this FUD man -- it integrates right now:
http://linux.adaptec.com/sas/

> independent from SPI.  I'm going to be putting time and effort into 
> moving the SCSI core away from SPI, so that SAS can be properly integrated.

So you are going to give all currently existsing legacy LLDD
a heart attack?

Or are you going to create new functionality as I had
outlined here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112794008820004&w=2

You know, "struct scsi_domain_device", proper LU
scannint, etc.

> All I've seen from you is
> (a) complaints that the SCSI core is too SPI-centric

I've been wanting to change this since 2003.  I
even wrote an email that I wanted to completely
rewrite SCSI Core for 2.7 in 2003.  See this email.
http://marc.theaimsgroup.com/?l=linux-scsi&m=104508658212335&w=2

Sadly as most discussions in linux-scsi nothing materializes,
patches get dropped, etc, etc, et.

> (b) a solution that does nothing to fix this

But it gets you one step closed to it.  It merges _cleanly_,
people can use it get comfortable with it and eventually
things else where would improve as people get comfortable
with it.

> My goal is Linux.  Always has been.  I put quality of Linux code, and 
> giving features to Linux users, above all else.  Have been doing so 
> regardless of who employs me, for many years now.
> 
> Maybe one day I will be independently wealthy, be a completely 
> independent Linux maintainer, and then people will have to find

Jeff, if you think that if one day if you became independently
wealthy you'd be an independent Linux maintainer, or
do _any_ kind of work, you need to mature a bit more.
I _guarantee_ you that in 5 years you'd think differently.

Independently wealthy people start doing charity work
and then they use that to get into politics, in order
to obtain that which lacks from just having a ton of money:
power.

	Luben

 
> something other than Red Hat as the reason for why their code is 
> receiving criticism.
> 
> 
> 
>>I doubt you've ever been honest with me.*  The reason is that
>>you are trying to push down my throat JB's "transport classes",
>>all the while you're saying I'm supposed to change other people's
>>code?
> 
> 
> To get a fully SPI-independent SCSI core, we must change other people's 
> code.  That's the way Linux works.  We evolve the existing code.
> 
> 	Jeff
> 
> 
> 

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

[Gerrit Huizenga]

On Thu, 29 Sep 2005 12:58:16 EDT, Luben Tuikov wrote:
> On 09/29/05 12:56, Jeff Garzik wrote:
> > Luben Tuikov wrote:
> > 
> >>On 09/29/05 11:17, Bernd Petrovitsch wrote:
> >>
> >>
> >>>Then submit your driver as a (separate) block device in parallel to the
> >>>existing SCSI subsystem. People will use it for/with other parts if it
> >>
> >>
> >>SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
> >>_We_ together can do this in parallel to the old SCSI Core.
> > 
> > 
> > You should have stated this plainly, from the start.
> > 
> > If you want to do your own SCSI layer, you need to do it at the block 
> > layer rather than poking around drivers/scsi/
> 
> So now you are saying that I should _not_ poke at drivers/scsi?
> (as I haven't done)
> 
> Are you going to make up your mind?

Luben, I think you are missing the distinction being made here and that
distinction is very important.

It is *critical* to hardware vendors, to the linux community, and even
at this point to some of your competitors in the HBA space that we find
the best solutions that work well for *everyone*.  The more often we
wind up with independent, unique stacks and unrelated methods and
mechanisms in the kernel, the more work we all have to do to support
Linux.  If every HBA out there that thought there were following a new
and interesting technology and were going to code to the perfect ISO
or T10 or IETF layering model, the linux kernel would be one huge,
inconsistent, bloated stinking mess for the rest of us to support.

Worse, all of our customers would see different behaviors in semantics,
functionality, and support matrices for every HBA, hardware component,
or combination of platform/HBA/storage subsystem.

I believe that for you personally to find success in the Linux development
community (much as you probably do in the standards or HBA community)
is that you have to talk off your personal hat, you have to take off
your employer's hat, and you must put on the Linux community hat for
a while and see through their eyes.

In this case, Jeff and others are providing two options with a common
goal.  The common goal is to increase the overall amount of commonality
and common code in Linux in this case.

You can do that two ways:  Start with a new SCSI core library and show
with code how it works for multiple HBA vendors (this includes working
with your competitors!) OR help to evolve the current code to better
address your needs while not breaking the needs of other consumers.

Either approach is valid.  You can start sending patches to update the
SCSI core code to simplify your driver and fit with the current
community model, OR you can put forward not just a model but the
libraries and proof-of-concepts (possibly while working with other
HBA vendors) in the form of Linux kernel code to demonstrate the
viability of a new stack which satisfies the wider community goals of
ease of maintainence and ease of understanding over time.

In general, if you think you see a contraction coming from the community,
I'd encourage you to look more closely - there are some strong guiding
principles for the community.

I suggest reading through a few of these resources which might help:

http://lists.osdl.org/pipermail/os_drivers/attachments/20050426/261c7d9d/DeviceDriverDevelopmentPlan-v.02-0001.pdf

http://www.madrone.org/mentor/linux-mentoring.pdf

I'm sure others have simmilar materials floating around.  You are not
the first person to suffer from culture shock here but the sooner you
understand the goals of the community and show how to help meet those
goals (hopefully with code to substantiate your goals, and the ability
to incorporate feedback and give feedback) the sooner we'll have a working
driver in mainline.

gerrit

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

[John Stoffel]

Luben,

I'd really prefer if you'd just stop on your tirade and just send in a
10 line patch for the existing linux SCSI subsystem to fix something
you think is wrong. 

Code talks, bullshit walks.  

Sure, Linux SCSI might not be ideal, but how many people do you know
have SAS storage on their home PCs right now?  Heck, I don't have SATA
or PIV on my home system!  

And as a customer of Adaptec hardware, I'm getting to the point of
seriously taking my money and going elsewhere for my storage needs.
If you are a general example of how Adaptec works with its customers,
then I want nothing to do with you or your products.  

Sure, I know you think Linux is stuck in the past, so help us move to
the future in small baby steps.  It doesn't require big huge leaps
like you're proposing.  I mean, have you actually tried to your old
legacy SCSI controllers in a system with your new hardware?  How did
your testing go?  

Now I'm not a programmer, and I can't talk like one, but in my real
life job I'm a SysAdmin and knowing what I know about Adaptec's
interactions on this list will certainly color my perceptions of your
hardware and trying to make it work with my company.

John

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

[Jeff Garzik]

Stefan Richter wrote:
> Arjan van de Ven wrote:
> 
>> On Thu, 2005-09-29 at 06:04 +0200, Willy Tarreau wrote:
>>
>>> On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
>>>
>>>> Linux is about getting things done, not being religious about 
>>>> specifications.  You are way too focused on the SCSI specs, and 
>>>> missing the path we need to take to achieve additional flexibility.
> 
> 
> AFAIU, demands to get our concepts closer to SAM concepts are actually 
> motivated by this: To achieve additional flexibility. (In particular, to 
> ease integration of the various transports.)

That's what transport classes help achieve.

We just gotta move gunk from the core (HCIL etc.) to scsi_transport_spi 
before we get there.


> We implement drivers of initiators. (Well, targets too.) The specs 
> describe _what_ initiators do. Thereby they partly describe _how_ 
> drivers of initiators (our sw pieces) work.

Mostly agreed.  Some of the firmware-based and emulated SCSI stuff is a 
bit of an I_T mix.


> However it is very desirable to reflect layers and concepts of the SAM 
> in our stack. One class of reasons is maintainability. No person is able 
> to understand the stack; nor is a person able to consume and understand 
> all or even half of the SCSI specs. No person is able to construct a 
> mapping between the whole stack and the whole SCSI-3 Architecture Model 
> (in his mind or with pencil and paper...). Therefore there have to be 
> _components_ of the stack's architecture model which map 1:1 to 
> _components_ of the SCSI-3 Architecture Model.
> 
> Fortunately, SAM layers and concepts are already there in the stack, 
> although incomplete and incoherent. It will always be disputable _how_ 
> complete and coherent our software should be in this respect. However it 
> is out of a question that our software's architecture model might 
> arbitrarily differ from the SAM.

I think just about everybody agrees with this.

The current thread is more about the path to take, to get there...

The general point about specs is that you gotta think about them, not 
just blindly implement them.  SNIA for example is notorious for 
generating silly storage-related specifications.  And some of the T10 
stuff is... well... obviously designed by committee :)

	Jeff

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

[Stefan Richter]

Arjan van de Ven wrote:
> On Thu, 2005-09-29 at 06:04 +0200, Willy Tarreau wrote:
>>On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
>>
>>>Linux is about getting things done, not being religious about 
>>>specifications.  You are way too focused on the SCSI specs, and missing 
>>>the path we need to take to achieve additional flexibility.

AFAIU, demands to get our concepts closer to SAM concepts are actually 
motivated by this: To achieve additional flexibility. (In particular, to 
ease integration of the various transports.)

>>>With Linux, it's all about evolution and the path we take.
>>
>>Hmmm... I'm fine with "not being religious about specs", but I hope we
>>try to respect them as much as possible
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

We implement drivers of initiators. (Well, targets too.) The specs 
describe _what_ initiators do. Thereby they partly describe _how_ 
drivers of initiators (our sw pieces) work.

> (I know the scsi stuff also provides sort of a reference "here is how
> you can do it in sw" but I see that more as you "you need this
> functionality" not "you need this exact architecture in your software")

This is correct. The SAM is what it is --- the SCSI-3 Architecture 
Model, not the architecture model of Linux' SCSI stack.

However it is very desirable to reflect layers and concepts of the SAM 
in our stack. One class of reasons is maintainability. No person is able 
to understand the stack; nor is a person able to consume and understand 
all or even half of the SCSI specs. No person is able to construct a 
mapping between the whole stack and the whole SCSI-3 Architecture Model 
(in his mind or with pencil and paper...). Therefore there have to be 
_components_ of the stack's architecture model which map 1:1 to 
_components_ of the SCSI-3 Architecture Model.

Fortunately, SAM layers and concepts are already there in the stack, 
although incomplete and incoherent. It will always be disputable _how_ 
complete and coherent our software should be in this respect. However it 
is out of a question that our software's architecture model might 
arbitrarily differ from the SAM.
-- 
Stefan Richter
-=====-=-=-= =--= ===-=
http://arcgraph.de/sr/

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

[Bernd Petrovitsch]

On Thu, 2005-09-29 at 12:33 -0400, Luben Tuikov wrote:
> On 09/29/05 11:17, Bernd Petrovitsch wrote:
[...] 
> > Then submit your driver as a (separate) block device in parallel to the
> > existing SCSI subsystem. People will use it for/with other parts if it
> 
> SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
> _We_ together can do this in parallel to the old SCSI Core.
>
> This is the whole idea.

The question is: Who starts and leads seriously this effort (and takes
in the course others with him)?
Just telling others where to go and waiting until they carry you there
usually doesn't succeed if you are not the boss of them (and/or they
are free to leave at any time without significant punishment).

> > makes sense (and you - as the maintainer - accept their patches). And in
[...]
> > a few years the "old" SCSI core fades out as legacy drives fade out (or
> > they will happily coexist forever).
> 
> Yep, I've been saying this since 2002.  On the linux-scsi ML.

Perhaps speaking is not enough and work should follow?
All people who really do the work like those others standing beneath
(possibly doing their own thing) and telling them how to do their own
work best.

> And this is the problem: *you* and "the community" see things in
> *this* way:  "your balls - my balls", "yours/mine".

It's at most (and actually exactly) "my work - your work", not "my balls
- your balls" (or "code" or whatever).
If you want to play "our work" (read: team[0] work), than you have to
cope with others (and they with you), their - probably historically
grown - design (even if it is wrong), etc.
If this doesn't work (and ATM I have this impression) for whatever
reason, the second step is "my work, your work".
And if two (or more) people have different design opinions (and
different opinions about "quality" and/or "correct vs wrong" - I can't
decide since I have virtually no knowledge about SCSI core internals,
discussions on the Linux-SCSI-ML, etc. to decide - not even for me -,
who is "right" and/or "wrong" in which aspect or in general), it comes
down to "better the not-so-good design and working code than the best
design and no code".
So just copy the old core, throw out what you don't want, need and/or
like and voila. If it *is* "better", it will succeed and people will
come and help.
Of course it is probably more work in the short and in the long run to
maintain a separate block driver for SAS storage, but it is at least a
possible solution.
Perhaps all relevant people will see that the difference is small enough
to converge to some point in between.

	Bernd

[0]: Not in the ironic interpretation in German which translates roughly
     to "great, another one does it".
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/29/05 11:20, Jeff Garzik wrote:
> 
>>>Arjan, I'll be your best friend here:
>>>Never say this in public or in an intervew.
>>
>>
>>It's hard-earned experience.  We constantly have to teach hardware 
>>vendors how to write good drivers.
> 
> 
> I'm sure you have.  Hardware vendors are lost without
> Jeff, James Bottomley and Christoph.
> 
> You see, it is because of your _enormous_ ego as shown
> above, that the code is being blocked.

No, I was referring to things such as, e.g.
	http://people.redhat.com/arjanv/olspaper.pdf
	http://people.redhat.com/arjanv/OLS.pdf

It has nothing to do with ego, just hard-won experience.

There are bunches of hardware vendors who have their patches merged 
immediately after posting.  They get it.  They have internalized the 
reasons why Linux drivers look the way they do.


>>As a tangent, I already have a design for a Linux filesystem that makes 
>>use of SCSI object-based storage (to James's horror, no doubt :)).  It's 
>>a fun thing to ponder.
> 
> 
> Ok, so the way I see it you want to show who has got
> the bigger balls?
> 
> Jeff, I have *worked* on a Linux OBD-based filesystem.
> 
> Are you going to stop this self-gratifying stuff?

Oh good grief.  It was an example, silly.  Trying to lighten the mood, even.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/29/05 12:56, Jeff Garzik wrote:
> 
>>Luben Tuikov wrote:
>>
>>
>>>On 09/29/05 11:17, Bernd Petrovitsch wrote:
>>>
>>>
>>>
>>>>Then submit your driver as a (separate) block device in parallel to the
>>>>existing SCSI subsystem. People will use it for/with other parts if it
>>>
>>>
>>>SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
>>>_We_ together can do this in parallel to the old SCSI Core.
>>
>>
>>You should have stated this plainly, from the start.
>>
>>If you want to do your own SCSI layer, you need to do it at the block 
>>layer rather than poking around drivers/scsi/
> 
> 
> So now you are saying that I should _not_ poke at drivers/scsi?
> (as I haven't done)
> 
> Are you going to make up your mind?

Are you:  are you going to rewrite the SCSI core, or work to improve the 
existing one?

Your choice, not mine.  Your time, not mine.

	Jeff

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

[Luben Tuikov]

On 09/29/05 12:56, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>On 09/29/05 11:17, Bernd Petrovitsch wrote:
>>
>>
>>>Then submit your driver as a (separate) block device in parallel to the
>>>existing SCSI subsystem. People will use it for/with other parts if it
>>
>>
>>SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
>>_We_ together can do this in parallel to the old SCSI Core.
> 
> 
> You should have stated this plainly, from the start.
> 
> If you want to do your own SCSI layer, you need to do it at the block 
> layer rather than poking around drivers/scsi/

So now you are saying that I should _not_ poke at drivers/scsi?
(as I haven't done)

Are you going to make up your mind?

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/29/05 11:17, Bernd Petrovitsch wrote:
> 
>>Then submit your driver as a (separate) block device in parallel to the
>>existing SCSI subsystem. People will use it for/with other parts if it
> 
> 
> SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
> _We_ together can do this in parallel to the old SCSI Core.

You should have stated this plainly, from the start.

If you want to do your own SCSI layer, you need to do it at the block 
layer rather than poking around drivers/scsi/

	Jeff

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

[Luben Tuikov]

On 09/29/05 11:20, Jeff Garzik wrote:
>>Arjan, I'll be your best friend here:
>>Never say this in public or in an intervew.
> 
> 
> It's hard-earned experience.  We constantly have to teach hardware 
> vendors how to write good drivers.

I'm sure you have.  Hardware vendors are lost without
Jeff, James Bottomley and Christoph.

You see, it is because of your _enormous_ ego as shown
above, that the code is being blocked.

> At some point you have to step away from the spec, and ask yourself what 
> makes sense for Linux.

I'm sure -- flush interoperability down the drain.

> I've already had to poke T10 when they put silly 
> things in the SAT spec.

Surely they are lost without you.

> As a tangent, I already have a design for a Linux filesystem that makes 
> use of SCSI object-based storage (to James's horror, no doubt :)).  It's 
> a fun thing to ponder.

Ok, so the way I see it you want to show who has got
the bigger balls?

Jeff, I have *worked* on a Linux OBD-based filesystem.

Are you going to stop this self-gratifying stuff?

>>Hardware folks needs to work with software folks and
>>software folks need to work with hardware folks.
> 
> Certainly.  The historical disconnect is where hardware vendors tend to 
> presume They Know Best, when in reality it needs to be an equal 
> tradeoff.  Hardware vendors must admit they don't know Linux, and Linux 
> developers must admit that hardware vendors know their own hardware 
> better than anyone else.

Reflection of above:
  The historical disconnect is where "the community" tend to 
presume They Know Best, when in reality it needs to be an equal 
tradeoff.  "The community" must admit they don't know hardware,
and hardware developers must admit that "the community" know their
own code better than anyone else.

Jeff, if you had started looking at the design and firmware
of any new SCSI storage chip, you'd see how incredibly similar
it is to the transport it defines, and thus to SAM, since the
transport itself has to comply with SAM for interoperability
(TMF and all).

Linux SCSI does _not_ need to do "its own thing".  There are
perfectly well defined specs, telling you how things are
conceptually _and_ in the physical world.

In order to control those objects, you need to represent
them internally (you can learn this either in neuroscience
class or in OOD & OOP comp sci classes) as you can see has
been done in the SAS Transport Layer code.

So if you want _better control_, higher quality you need
to invent _your own_ stuff as _little as possible_ and
represent things as they are.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> of SAS.  THE REASON THEY WERE INTRODUCED INTO LINUX BY JB IS TO
> ACCOMODATE MPT-based SOLUTIONS FROM TWIDDLING WITH IOCTLS!

Wrong.  This shows you fundamentally don't understand transport classes 
at all.

AFAIK, the first transport class was FC, for qla2xxx.

Read the code to see how FC avoids the SPI-centric scan -- an example of 
transport independence.


> How do I know this: simple: JB's "transport attributes" have
> NOTHING to do with SAM.
> 
> They break the layering architecture for one, and are
> ATTRIBUTE EXPORTING FACILITY for another.

Transport class == transport layer.  Eventually this will sink in.

Transport class allows for complete transport independence, be it SAS, 
FC, iSCSI, or other.


> And as you can see, Linux today is the most anal retentive as it
> has ever been (e.g. SAS, reiser4, and other (revolutionary) technologies).
> 
> Remember, you can only go _down_ from the top.  So please
> do not say
>    "Linux is the most successful it's ever been."

We've still got all that Microsoft and old-Unix marketshare to steal :)


> It's too immature as it means that it would either go down
> or that it cannot become even _more_ successful.
> 
> 
>>The rest of the Linux-SCSI devs are trying to make it less SPI-centric. 
>>  Rather than just complain, we're doing something about it.
> 
> 
> Oh this is such a political sap, Jeff -- I cannot believe
> you're actually saying this.

I'm merely stating I'm submitting patches to clean up SCSI core.  Others 
have submitted far more patches than I.  And further patches to SCSI 
core are needed to properly integrate SAS as a transport completely 
independent from SPI.  I'm going to be putting time and effort into 
moving the SCSI core away from SPI, so that SAS can be properly integrated.

All I've seen from you is
(a) complaints that the SCSI core is too SPI-centric
(b) a solution that does nothing to fix this


> Who are you pleasing?  Your management?

My goal is Linux.  Always has been.  I put quality of Linux code, and 
giving features to Linux users, above all else.  Have been doing so 
regardless of who employs me, for many years now.

Maybe one day I will be independently wealthy, be a completely 
independent Linux maintainer, and then people will have to find 
something other than Red Hat as the reason for why their code is 
receiving criticism.


> I doubt you've ever been honest with me.*  The reason is that
> you are trying to push down my throat JB's "transport classes",
> all the while you're saying I'm supposed to change other people's
> code?

To get a fully SPI-independent SCSI core, we must change other people's 
code.  That's the way Linux works.  We evolve the existing code.

	Jeff

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

[Luben Tuikov]

On 09/29/05 11:17, Bernd Petrovitsch wrote:
> 
> Then submit your driver as a (separate) block device in parallel to the
> existing SCSI subsystem. People will use it for/with other parts if it

SAS is ultimately SCSI.  I'll just have to write my own SCSI core.
_We_ together can do this in parallel to the old SCSI Core.

This is the whole idea.

> makes sense (and you - as the maintainer - accept their patches). And in

You see, at my age and my situation, I no longer see this as
"my balls - your balls".  What matters to me is good design,
quality code, customer satisfaction, bottom line.

E.g. I'm quite a liberal person and I wouldn't block
or stop new technologes from going into Linux on the basis
and merit of my not understanidn that particular new technology.

The bottom line is not "my balls - your balls" but the wide
spread use of Linux and "storage OS of choice".  Not "hobbyist
OS of choice" and not "let me play Robin Hood".

> a few years the "old" SCSI core fades out as legacy drives fade out (or
> they will happily coexist forever).

Yep, I've been saying this since 2002.  On the linux-scsi ML.

> The point is: If *you* want it that way, *you* must go that way (and do
> not expect others to do it just that *you* get *your* driver merged).
> You are the maintainer of the new stuff and (almost) everything will
> work as you want.

And this is the problem: *you* and "the community" see things in
*this* way:  "your balls - my balls", "yours/mine".

While I see things like this: new technology, absolve, use, move on.

As to your comment above, it's not about how *I* see things.
It's about how things _actually_ *are*:
http://www.t10.org/ftp/t10/drafts/sam4/sam4r03.pdf

> It might not be the cleanest or most elegant solution in the world, but
> if it works, who cares and why?

Turn the table around: can _I_ pose this question to JB and Christoph?

(since they are the ones who think this of SAM/SPC)

> Where is now the real problem?
> I can't see one.

Me neither.

	Luben

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

[Luben Tuikov]

On 09/29/05 11:08, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>  hardware implementation  (interconnect, SAM 4.15, 1.3)
>>      firmware implementation  (interconnect, SDS, SAM 4.6, 1.3)
>>          LLDD                     (SAM, section 5, 6, 7)
>>             Transport Layer          (SAM 4.15, SAS)
>>                  SCSI Core             (SAM section 4,5,8)
>>                     Commmand Sets        (SAM section 1)
> 
> 
> Transport class + libsas achieves this.

This is *WRONG*.  (see below)

And it doesn't "achieve" this.  Stop the FUD.
There is a _reason_ why it is the way it is.

> Maybe I will have to demonstrate using code...

Jeff,

There is a _reason_ why technical people separate concepts
in _layers_.

There is a _reason_ why technical people use Object Oriented
Paradigms describing models and design.

Do you know _what_ that reason is?

Or should I leave you to "demonstrate with code"?

Seeing that you keep _persisting_ in your ways,
I'll leave it for you to "enrich" Linux SCSI in
your "demonstrate with code".

	Luben

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

[Luben Tuikov]

On 09/29/05 10:48, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>All the while, Linux _development_, seems to follow some kind
>>"yours/mine", "gimme that/take that" kindergarten kind of way.
>>The reason I'm saying this is that _every_ successful entity
>>(person, corporation, etc) knows that in order to _survive_
>>it needs to _quickly adapt to new things_: new technologies,
>>new trends, new fads, etc.
> 
> 
> The core problem is that a SAM-friendly path to SAS has already been 
> chosen -- transport classes -- and your driver isn't following this path.

Man you never stop do you?

I repeat again (I'll cut and paste this):

When JB's transport classes were introduced there was NO MENTIONING
of SAS.  THE REASON THEY WERE INTRODUCED INTO LINUX BY JB IS TO
ACCOMODATE MPT-based SOLUTIONS FROM TWIDDLING WITH IOCTLS!

How do I know this: simple: JB's "transport attributes" have
NOTHING to do with SAM.

They break the layering architecture for one, and are
ATTRIBUTE EXPORTING FACILITY for another.

I understand that you want to preserve your friend's
bal^w^w^wpride but, lets face it:
  I do not try to shove my solution down JB's throat.

As I've said many times: they are different due to
the *technology they represent*, which differs in
implmentation, and they can coexist!

If you can say this statement:
  "The core problem is that a SAM-friendly path to SAS
   has already been chosen -- transport classes -- and
   your driver isn't following this path."

This means that you have NO CLUE ABOUT SAS or SAM!

I certainly hope that things would improve once you
start reading specs and talking to the engineers
who designed BCM8603.  (If you are still going to
write their driver for them.)

> If we choose a new path every six months, we'll never arrive at the 
> destination.

No one is choosing a new path every six months.

And this isn't a new path for _everybody_ to follow, it is only
for LLDD who need a transport layer to drive the transport
they expose an interface to.

I'm _not_ choosing a new path.  No one is required to
"follow" this.  This is just _technology_ for LLDD who _need_
a management layer, and who _cannot_ inteface with a high
level such as SCSI Core.

> Linux today is the most successful its ever been.  This system, however 
> strange it may seem, does work.

And as you can see, Linux today is the most anal retentive as it
has ever been (e.g. SAS, reiser4, and other (revolutionary) technologies).

Remember, you can only go _down_ from the top.  So please
do not say
   "Linux is the most successful it's ever been."

It's too immature as it means that it would either go down
or that it cannot become even _more_ successful.

> The rest of the Linux-SCSI devs are trying to make it less SPI-centric. 
>   Rather than just complain, we're doing something about it.

Oh this is such a political sap, Jeff -- I cannot believe
you're actually saying this.

Who are you pleasing?  Your management?

I've been asking for movement AWAY from HCIL from early
2003, when you were writing libata, remember? Or do you
want a link to marc.10east.com?

Stop this political BS sap "we're doing something about it", please.

I suggested native scsi_target support so long ago, only to get
snuffed at.

>>Many things are left to the whim of developers whose educational
>>and technical background could be in question especially when
>>your only communication with them is via email.
> 
> Background is irrelevant.  Only results matter.  Linux is a meritocracy.

Single line statements like this with 0-content, FUD-like,
only for you to reply right away, do not _contribute_ anything.

You're just throwing sand in the eyes of managament reading this.

> Spare me your paranoia.  I've been 100% honest with you in every email 
> I've written.
> 
> You -should- change other people's code.  That's how Linux gets better.

I doubt you've ever been honest with me.*  The reason is that
you are trying to push down my throat JB's "transport classes",
all the while you're saying I'm supposed to change other people's
code?

Just see how you started this email (above).

So please, don't try to get out of any situation turning 180
degrees around.

* Well, maybe you _are_ 100% honest with me.  Maybe you really
do believe that your friend JB's "transport _attributes_" code
has anything to do with SAM.

> When I chose a better path for libata's error handling, the first step 
> in that process was changing the locking, and modifying almost every 
> $!#$@! SCSI driver in the kernel.  Rather than forever complaining about 
> an outdated SCSI layer, I stepped up and fixed things.

I flipped a card: "You'll get a promotion soon!".

What else can I reply to a self-gratifying statment like this?

Can I reply with someting like: "See my SAS stuff -- how it
truthfully represents the whole domain and gives complete
control of it over to user space? See?"

> SCSI work is speeding up.  The SCSI core has come a -long- way in the 
> past couple years.  2.6.x SCSI is light years ahead of 2.4.x SCSI.

Well, this only tell you the (bad) state of affairs of _2.4.x_ SCSI.
This does _not_ tell you the state of affairs of 2.6.x SCSI.

2.6.x SCSI is light years _behind_ SAM.

	Luben

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

[Moore, Eric Dean]

On Thursday, September 29, 2005 6:46 AM, Luben Tuikov wrote:

> 
> On 09/28/05 18:17, Moore, Eric Dean wrote:
> > Can you stop this tirade, e.g. conspiracy theory,
> > in regards to LSI/MPT and the transport layer?
> 
> What conspiracy theory?
> 
> Oh you mean that one _technology_ is in the kernel
> and another distinct, radically _different_ is NOT?
> 
> Oh you mean that conspiracy theory?

Thats just plain crap.  And your trash talking is plan crap.
My sas drivers have been rejected for
more than a year now. They were only accepted in the  
past week.  During that time, I've had to endure many changes
in the driver to get them where they were accepted.  And that
has been very painful. I hope you know that we have support
CSMI/SDI interface (yes, we are SAS by the way). 
How do you suggest we do that? The IOCTLS were rejected.

> 
> > That is not the case.   There will be other sas 
> 
> I don't see our driver in the kernel, do you?
> 
> > solutions that implement discovery, and 
> > sas/sata translation in firmware, higher level
> > event handling.
> 
> Yes, and they would all be MPT-like technology.
> I don't have a problem with that.
> 
> What I have a problem with is that you folks
> just sit and watch this, while you could explain
> to James et al, that indeed the technologies
> are different and there is no reason NOT to include
> one but leave the other out.

Ok, fine, James Let them all in.  

I have never said to alientate any other technology.  
When did I ever say that?
I'm still not convinced that your sas transport will 
work with any other technology but yours.  Or will it?

Christophs sas transport layer is generic?  I see nothing there
that says "this is MPT".   I thought all along since OLS, that you 
were going to develop a layer that would work below it
for cards that don't have firmware assist? 
Are you working with these guys on that?   I thought that is 
what you were doing, or maybe I'm misunderstanding something here.
 
> 
> I was hoping you'd say something like, "Yeah, the
> technologies are different -- I don't see why one
> should be in and another not."
> 

I agree with you.  

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/29/05 03:44, Arjan van de Ven wrote:
> 
>>a spec describes how the hw works... how we do the sw piece is up to
>>us ;)
> 
> 
> Arjan, I'll be your best friend here:
> Never say this in public or in an intervew.

It's hard-earned experience.  We constantly have to teach hardware 
vendors how to write good drivers.

At some point you have to step away from the spec, and ask yourself what 
makes sense for Linux.  I've already had to poke T10 when they put silly 
things in the SAT spec.

As a tangent, I already have a design for a Linux filesystem that makes 
use of SCSI object-based storage (to James's horror, no doubt :)).  It's 
a fun thing to ponder.


> Hardware folks needs to work with software folks and
> software folks need to work with hardware folks.

Certainly.  The historical disconnect is where hardware vendors tend to 
presume They Know Best, when in reality it needs to be an equal 
tradeoff.  Hardware vendors must admit they don't know Linux, and Linux 
developers must admit that hardware vendors know their own hardware 
better than anyone else.

	Jeff

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

[Bernd Petrovitsch]

On Thu, 2005-09-29 at 10:33 -0400, Luben Tuikov wrote:
[...]
> Linux _development_ needs to catch up to Linux _deployment_.

That is probably the root and single cause of quality problems in
companies: Deployment folks (read: sales) set the delivery date (and get
the bonus for selling) and the rest (read: tech folks) have to follow,
no matter what (and get the blame for being late and buggy).
Or why do you think that MSFT has such quite crappy software?

> Currently they are two different worlds.

ACK - in the commercial world (and the bigger the company the worse
because sales people are far more distant from the tech people).

[ software rewrite ]
> > Maybe it can simply coexist with another new subsystem. This is what
> 
> Now _this_ is a smart suggestion: it wouldn't break legacy hardware
> _and_ it would give Linux SCSI a fresh start.
>
> Next year, your new serverboard wouldn't have any of those old
> cumbersome storage chips to worry about.  It would have only one
> storage chip which could do SAS and SATA and that'd be that.
> Why would anyone need this fat, old semanticaly overloaded,
> SPI-centric SCSI Core?

Then submit your driver as a (separate) block device in parallel to the
existing SCSI subsystem. People will use it for/with other parts if it
makes sense (and you - as the maintainer - accept their patches). And in
a few years the "old" SCSI core fades out as legacy drives fade out (or
they will happily coexist forever).
The point is: If *you* want it that way, *you* must go that way (and do
not expect others to do it just that *you* get *your* driver merged).
You are the maintainer of the new stuff and (almost) everything will
work as you want.
It might not be the cleanest or most elegant solution in the world, but
if it works, who cares and why?
Where is now the real problem?
I can't see one.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[grundig]

El Thu, 29 Sep 2005 10:33:03 -0400,
Luben Tuikov <luben_tuikov@adaptec.com> escribió:

> The reason I'm saying this is that _every_ successful entity
> (person, corporation, etc) knows that in order to _survive_
> it needs to _quickly adapt to new things_: new technologies,
> new trends, new fads, etc.

[...]

> I wish Linux would return to its roots.

I don't know how things were when you started using linux but linux
has never been about that AFAIK. People usually buys windows
licenses for that ;)


> here.  (Other than ones I've seen at OLS.)  For all I know I could
> be having a discussion with a 9 year old kid, repeating SAM and SPC
> references over and over again.

Oh well. May be Christoph and James are behaving like 9-years-old
kids, but if that's true you're NOT BEING DIFFERENT than them if
you look a bit to your mails.

You can be pretty sure that at this stage everyone is looking you as a
9-years-old kid who is raving because his mother don't buy him a
candy. Maybe they're looking james and christoph int he same way
aswell, but that's their issue.

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

[Luben Tuikov]

On 09/29/05 03:44, Arjan van de Ven wrote:
> 
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)

Arjan, I'll be your best friend here:
Never say this in public or in an intervew.

Hardware folks needs to work with software folks and
software folks need to work with hardware folks.

This is what makes good design.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
>   hardware implementation  (interconnect, SAM 4.15, 1.3)
>       firmware implementation  (interconnect, SDS, SAM 4.6, 1.3)
>           LLDD                     (SAM, section 5, 6, 7)
>              Transport Layer          (SAM 4.15, SAS)
>                   SCSI Core             (SAM section 4,5,8)
>                      Commmand Sets        (SAM section 1)

Transport class + libsas achieves this.

Maybe I will have to demonstrate using code...

	Jeff

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

[Luben Tuikov]

On 09/28/05 18:43, Andre Hedrick wrote:
> I have a vested interest in the improvement of the Linux SCSI Core and
> wider adoption and support for SATA II and SAS controllers with their
> associated domains and transport.

Us and other companies too.

> Proving a better design with a migration path for integration is the key
> for success; however, I am not the person to be the political voice in the

Yes, _it is_ the key to success.

> James is king of the hill, and is reasonable to a point.  James also

Which "hill" is the question.  If he were reasonable, he'd
understand that the two technologies _are_ completely different and
distinct and he'd not try to shove HIS solution down my throat.
Just as I do not shove my solution in his throat.

The whole point is that MPT-based (IOP on package) solutions
_do not_ need a Transport Layer, since that Transport Layer
_is_ already present: in the firmware _and_ access to it
is _firmware_ dependent.

All the while open transport solutions (ours and apparently
Broadcoms') _expose_ the whole infrastructure and _give_ you
the chip as an interface to the interconnect.  So you actually
_need_ a transport management layer.  Now that transport
management layer sits _below_ SCSI Core and SCSI Core is
_unaware_ of the transport.

> follows a model of generalization v/s specific design.  Argh, this is not
> going to be an easy one to explain or back away from now.  Erm, inclusive
> API design is where I am wanting to go with this thought.

You can have inclusive API design for chips like AIC-94xx and BCM8603,
because they <see paragraph above>.

MPT-based ones <see paragraph above> would also use inclusive
design _for MPT-based chips_.

> Have you and company considered the approach of mapping to a library of
> sorts?

Hmm, it is not a library.

It is a layer, again, because of what the chip actually is, and because
of what it implements.

Take a look at the announcement text, I do give some description there
and in the code the drivers/scsi/sas-class/README file describes
the event/managment infrastructure.  Also you can take a look at the code.
http://linux.adaptec.com/sas/

What you'll see in the code is:

  hardware implementation  (interconnect, SAM 4.15, 1.3)
      firmware implementation  (interconnect, SDS, SAM 4.6, 1.3)
          LLDD                     (SAM, section 5, 6, 7)
             Transport Layer          (SAM 4.15, SAS)
                  SCSI Core             (SAM section 4,5,8)
                     Commmand Sets        (SAM section 1)

A very nice explanation in latest SAM4r03,
section 4.15 The SCSI model for distributed communications.

Now for MPT based solutions you have:

  LLDD                  (SAM, section 5, 6, 7)
     SCSI Core             (SAM section 4,5,8)
        Commmand Sets         (SAM section 1)

You see?  No Transport Layer between LLDD and SCSI Core!
Why?  Because all this work is done in FIRMWARE!

That is, the LLDD exports the LUs right into SCSI Core,
So in effect there is _no_ need for a software Transport
Layer.

Can we have a video/tele conference on this?

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> All the while, Linux _development_, seems to follow some kind
> "yours/mine", "gimme that/take that" kindergarten kind of way.
> The reason I'm saying this is that _every_ successful entity
> (person, corporation, etc) knows that in order to _survive_
> it needs to _quickly adapt to new things_: new technologies,
> new trends, new fads, etc.

The core problem is that a SAM-friendly path to SAS has already been 
chosen -- transport classes -- and your driver isn't following this path.

If we choose a new path every six months, we'll never arrive at the 
destination.


> Some companies are _fiercly_ trying to beat this _natural_
> course of History, into turning 180 degrees from their mindset
> every single year in order to chase the latest technology, the
> latest fad, in order to please customers and stay on top.
> 
> I wish Linux would return to its roots.

Linux today is the most successful its ever been.  This system, however 
strange it may seem, does work.


>>Hans Reiser once said that every software needs a complete rewrite
>>every 3 or 5 years (I don't precisely remember). I tend to agree
>>with him. Maybe it's time to completely rewrite the SCSI subsystem,
>>but maybe it will be too long, too risky and not worth the effort.
>>Maybe it can simply coexist with another new subsystem. This is what
> 
> 
> Now _this_ is a smart suggestion: it wouldn't break legacy hardware
> _and_ it would give Linux SCSI a fresh start.
> 
> Next year, your new serverboard wouldn't have any of those old
> cumbersome storage chips to worry about.  It would have only one
> storage chip which could do SAS and SATA and that'd be that.
> Why would anyone need this fat, old semanticaly overloaded,
> SPI-centric SCSI Core?

The rest of the Linux-SCSI devs are trying to make it less SPI-centric. 
  Rather than just complain, we're doing something about it.


> Foremost, this experience reminds other vendors that Linux
> _development_ model is _not_ en par with their Linux _deployment_
> model (i.e. for a business).
> 
> Many things are left to the whim of developers whose educational
> and technical background could be in question especially when
> your only communication with them is via email.

Background is irrelevant.  Only results matter.  Linux is a meritocracy.


> I'm not shoving my solution down the throats of LSI or James or
> Christoph.  Why?
>  - because the technologies are different,
>  - beacause I'm following a SAM model, they are not.
>  - and because I'm not changing anybody else's code but integrating
>    with it.
> 
> (Jeff, I know that on the 3rd point, you'd say "That's the problem,
> you should be improving SCSI Core", and I know that if I had been
> changing other people's code, you'd say "You should not change
> other people's code", so it's a win-win-manipulative situation
> for you.  I'm aware of that, spare your keystrokes.)

Spare me your paranoia.  I've been 100% honest with you in every email 
I've written.

You -should- change other people's code.  That's how Linux gets better.

When I chose a better path for libata's error handling, the first step 
in that process was changing the locking, and modifying almost every 
$!#$@! SCSI driver in the kernel.  Rather than forever complaining about 
an outdated SCSI layer, I stepped up and fixed things.


>>seems to matter much those days. In an ideal situation, 2.7 would
>>have been opened for a long time,
> 
> 
> Maybe things are slowing down for Linux?  Attitude?  Complacency?
> History?  Who knows?

SCSI work is speeding up.  The SCSI core has come a -long- way in the 
past couple years.  2.6.x SCSI is light years ahead of 2.4.x SCSI.

	Jeff

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

[Luben Tuikov]

On 09/28/05 18:35, Willy Tarreau wrote:
> There are people buying expensive hardware. The type of hardware
> that costs $100k for just a few CPUs. Those people don't buy "the
> Adaptec XXX which runs best with Red Hat Enterprise" nor the "LSI
> YYY which runs best with Solaris", they buy a few $100k systems
> with 3 TB disk to store their monthly logs. They cannot even imagine
> that the hardware in the $100k system will not be fully supported by
> some recent OS, that's just plain silly. The OS cost is just a water
> drop in the middle of this. When they install Solaris on it because
> they're used to run it, it just works. When I sometimes just show
> them that Solaris is not adequate for daily greps in logs, and I show
> them how faster it is on a $1k Linux machine in the next rack, they
> feel they can switch to it easily. But if they discover that this
> system does not correctly support their $100k hardware, do you know
> which one was is the crap ? the $300 Red Hat or the $100k hardware ?
> [ oh, BTW, I forgot to tell you : they say "Red Hat", and not "Linux"
> because it does not sound like what they long considered an OS for
> tamagotchis - to use their own words - :-( ]

Yes, all true.

Sadly, most developers here do not _use_ Linux, or are at least
shielded from using Linux, in a _business_.

All the while, Linux _development_, seems to follow some kind
"yours/mine", "gimme that/take that" kindergarten kind of way.
The reason I'm saying this is that _every_ successful entity
(person, corporation, etc) knows that in order to _survive_
it needs to _quickly adapt to new things_: new technologies,
new trends, new fads, etc.

But eventually, when entities get too successful, they
get _complacent_ (with themselves) and turning _away_
from their younger style of functioning (of absolving
everything in order to get successful in the first place).

All this, of course, it the _natural_ way of history.  We
see it when studying History, and we see it every day
when reading the Technology section of our favourite
publication.

Some companies are _fiercly_ trying to beat this _natural_
course of History, into turning 180 degrees from their mindset
every single year in order to chase the latest technology, the
latest fad, in order to please customers and stay on top.

I wish Linux would return to its roots.

> And when they go to adaptec site to find latest drivers and they only
> find patches which forces them to find another Linux to install the
> sources and guess how to patch and build, do you know which OS they
> consider as hobbyist's ? The Red Hat ! (which they can call "Linux"
> again then).

OMG, "hobbyist" -- this so perfectly describes it!  LOL

So now, if there is any coroprate management from RH here reading
this they'd take heed in this.

Linux _development_ needs to catch up to Linux _deployment_.

Currently they are two different worlds.

> Hans Reiser once said that every software needs a complete rewrite
> every 3 or 5 years (I don't precisely remember). I tend to agree
> with him. Maybe it's time to completely rewrite the SCSI subsystem,
> but maybe it will be too long, too risky and not worth the effort.
> Maybe it can simply coexist with another new subsystem. This is what

Now _this_ is a smart suggestion: it wouldn't break legacy hardware
_and_ it would give Linux SCSI a fresh start.

Next year, your new serverboard wouldn't have any of those old
cumbersome storage chips to worry about.  It would have only one
storage chip which could do SAS and SATA and that'd be that.
Why would anyone need this fat, old semanticaly overloaded,
SPI-centric SCSI Core?

> Luben, you seem to have enough knowledge to draw both diagrams
> side-by-side :
>  - the T10 spec with colors on the boxes covered by your work
>  - the Linux view of SCSI
> 
> Perhaps we will see that current code can be extended without too
> much work, or perhaps we will see that it's definitely a dead end
> and that a new design will help a lot.

Yes, I'll get that jpg and try to color it, but there's
also a lot of other components (Interconnect, SDS,
Application Client) which are not visible in this interconnect.

I'll try to get something descriptive.

> Anyway Luben, I fear that for some time, you'll have to provide
> pre-patched sources as well as binary kernels to enterprise customers
> who still try to get Linux working in production. I hope that this sad
> experience will not discourage other vendors from trying to take the
> opensource wagon, as it clearly brings fuel to closed-source drivers
> at the moment (no need to argue).

Foremost, this experience reminds other vendors that Linux
_development_ model is _not_ en par with their Linux _deployment_
model (i.e. for a business).

Many things are left to the whim of developers whose educational
and technical background could be in question especially when
your only communication with them is via email.

I mean -- I don't even know the _age_ ballpark of most developers
here.  (Other than ones I've seen at OLS.)  For all I know I could
be having a discussion with a 9 year old kid, repeating SAM and SPC
references over and over again.

I just don't see the technologically savvy and _open_ community
here.

> Eventhough I don't have SAS, I sincerely hope that a quick and smart
> solution will be found which keeps everyone's pride intact, as it

I'm not shoving my solution down the throats of LSI or James or
Christoph.  Why?
 - because the technologies are different,
 - beacause I'm following a SAM model, they are not.
 - and because I'm not changing anybody else's code but integrating
   with it.

(Jeff, I know that on the 3rd point, you'd say "That's the problem,
you should be improving SCSI Core", and I know that if I had been
changing other people's code, you'd say "You should not change
other people's code", so it's a win-win-manipulative situation
for you.  I'm aware of that, spare your keystrokes.)

This is all _fine_ with me as long as they are not shoving down
my throat their solution.

I wonder the pride to technological merit ratio in Linux SCSI.

> seems to matter much those days. In an ideal situation, 2.7 would
> have been opened for a long time,

Maybe things are slowing down for Linux?  Attitude?  Complacency?
History?  Who knows?

> and Luben's code would have been
> discussed to death as a new development needed to be merged before

We did have a Storage BOF (Birds Of Feather) at the Ottawa Linux
Symposium (OLS) in July this year.  It was called "SAS" and someone
made me do the presentation.  Drawing on a white board several layers
and how they communicate with each other, how things work, why they
work the way they work, how they are shown and represented and why.

The response I got from James and Chritsoph was:
"The sysfs tree would be too deep."

The next day I learned that such argument is bogus and a sysfs
tree can be as deep as the representation calls for.

So you see, _this_ is where we started -- with _this_ kind
of argument: "The sysfs tree would be too deep."

BTW, James already had already had my code for about two
weeks before OLS.

	Luben

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

[Luben Tuikov]

On 09/28/05 18:17, Moore, Eric Dean wrote:
> Can you stop this tirade, e.g. conspiracy theory,
> in regards to LSI/MPT and the transport layer?

What conspiracy theory?

Oh you mean that one _technology_ is in the kernel
and another distinct, radically _different_ is NOT?

Oh you mean that conspiracy theory?

> That is not the case.   There will be other sas 

I don't see our driver in the kernel, do you?

> solutions that implement discovery, and 
> sas/sata translation in firmware, higher level
> event handling.

Yes, and they would all be MPT-like technology.
I don't have a problem with that.

What I have a problem with is that you folks
just sit and watch this, while you could explain
to James et al, that indeed the technologies
are different and there is no reason NOT to include
one but leave the other out.

>>See, I've mentioned many times that the two
>>radically different technologies can coexist.
>>But I've not heard any technical word
>>from the other guys: you.
> 
> I just don't have time to engage you.
> I've got work to do, customer requests, issues,
> etc.

:-)  That a nice way to get out of the situation.

I was hoping you'd say something like, "Yeah, the
technologies are different -- I don't see why one
should be in and another not."

	Luben

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

[Arjan van de Ven]

On Thu, 2005-09-29 at 06:04 +0200, Willy Tarreau wrote:
> On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
> > Linux is about getting things done, not being religious about 
> > specifications.  You are way too focused on the SCSI specs, and missing 
> > the path we need to take to achieve additional flexibility.
> > 
> > With Linux, it's all about evolution and the path we take.
> 
> Hmmm... I'm fine with "not being religious about specs", but I hope we
> try to respect them as much as possible

a spec describes how the hw works... how we do the sw piece is up to
us ;)

(I know the scsi stuff also provides sort of a reference "here is how
you can do it in sw" but I see that more as you "you need this
functionality" not "you need this exact architecture in your software")

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

[David S. Miller]

From: Andre Hedrick <andre@linux-ide.org>
Date: Wed, 28 Sep 2005 22:30:58 -0700 (PDT)

> Not sure who to credit the following to:
> 
> When TOE's were introduced to Linux, there was a violent rejection of this
> hardware because Linux is superior in the NetStack than any other possible
> NetStack every created.
> 
> The point is there is a known history in Linux to reject things which
> steps on peoples' egos.

In that case, it is indeed a vendor trying to shove their particular
solution down our throats.  They never even attempt to try out the
alternatives, and we've even gone through the trouble of coming up
with several.  And they do this because their whole buisness model is
all about their scheme to the exclusion of anything else, not because
what they have is better.

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

[Andre Hedrick]

Dave,

Was it really necessary to this far and rude?

I heard the snow is falling and there is a fresh shipment of hash headed
out to the slopes, don't be late.

Not sure who to credit the following to:

When TOE's were introduced to Linux, there was a violent rejection of this
hardware because Linux is superior in the NetStack than any other possible
NetStack every created.

The point is there is a known history in Linux to reject things which
steps on peoples' egos.

Have a great ski trip.

Cheers,

Andre

On Wed, 28 Sep 2005, David S. Miller wrote:

> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Wed, 28 Sep 2005 19:22:53 -0400
> 
> > Both Luben and his predecessor, Justin Gibbs, were severely dissatisfied 
> > with the SCSI core.  Often they have raised valid issues that need 
> > addressing, but their choice has been to work around or ignore existing 
> > code (and maintainers), rather than work with it, and fix it.
> 
> I'm in violent agreement here.
> 
> Justin was just as anti-social of an engineer as one could get.  And,
> when you put an ex-FreeBSD guy onto Linux driver maintainence, what in
> the world could anyone expect. :-)
> 
> For example, instead of accepting that the symbol "current" is a
> reserved symbol when compiling under the Linux kernel, he decided that
> "sticking a square peg into a round hole" was a better way to deal
> with this, and thus he put an "#undef current" into the adaptec driver
> instead of simply renaming a structure member from "current" to
> something else.
> 
> I don't know how else to define "control freak".
> -
> 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/
> 

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

[Willy Tarreau]

On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
> Linux is about getting things done, not being religious about 
> specifications.  You are way too focused on the SCSI specs, and missing 
> the path we need to take to achieve additional flexibility.
> 
> With Linux, it's all about evolution and the path we take.

Hmmm... I'm fine with "not being religious about specs", but I hope we
try to respect them as much as possible, because it's the only way to
get everything working and not get the finger pointed to when there's
a problem. When I put netfilter + window tracking in production 2 years
ago, there were a lot of drops (about 2% of sessions = ~40/s), because
shortcuts had been taken WRT rfc793 ("the specs"). Then, printing the
whole RFC+erratas was the only way to get the code working and
supporting the most bizarre cases that had previously been considered
stupid or impossible by the developpers (including me during the first
phase of the fixes).

I prefer that we stick to specs even if we just implement what we
*need* from them, leaving lots of blank boxes on the diagram, rather
than interprete them as we think would be better and get annoyed
everytime a vendor tries to adapt it to support his hardware.

> >By "too literal" do you mean "following specs too closely",
> >or do you mean "being realistic without tweaking things".
> 
> I mean, paying too much attention to specs at the expense of 
> understanding how Linux code needs to be shaped.

Both are true : Linux code needs to be shaped to match specs. We
must not spend time on what we don't need but we must respect the
model and layering, and that's true in any subsystem. Networking
for example, is very clean in this area. Even accelerations do
not break layering, it's just that some of the work can be pushed
down from layer to layer until one can process it (eg: checksums).
And when I worked on bonding, I did not have problems with it
breaking upper layers. I really believe that's important, it's
the first step to avoid spending time in debugging.

Cheers,
Willy

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

[David S. Miller]

From: Jeff Garzik <jgarzik@pobox.com>
Date: Wed, 28 Sep 2005 19:22:53 -0400

> Both Luben and his predecessor, Justin Gibbs, were severely dissatisfied 
> with the SCSI core.  Often they have raised valid issues that need 
> addressing, but their choice has been to work around or ignore existing 
> code (and maintainers), rather than work with it, and fix it.

I'm in violent agreement here.

Justin was just as anti-social of an engineer as one could get.  And,
when you put an ex-FreeBSD guy onto Linux driver maintainence, what in
the world could anyone expect. :-)

For example, instead of accepting that the symbol "current" is a
reserved symbol when compiling under the Linux kernel, he decided that
"sticking a square peg into a round hole" was a better way to deal
with this, and thus he put an "#undef current" into the adaptec driver
instead of simply renaming a structure member from "current" to
something else.

I don't know how else to define "control freak".

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

[Jeff Garzik]

Willy Tarreau wrote:
> And when they go to adaptec site to find latest drivers and they only
> find patches which forces them to find another Linux to install the
> sources and guess how to patch and build, do you know which OS they
> consider as hobbyist's ? The Red Hat ! (which they can call "Linux"
> again then).

Adaptec is unfortunately a special case.  QLogic and other enterprise 
vendors get along with quite well on $100k machines.

Both Luben and his predecessor, Justin Gibbs, were severely dissatisfied 
with the SCSI core.  Often they have raised valid issues that need 
addressing, but their choice has been to work around or ignore existing 
code (and maintainers), rather than work with it, and fix it.


> When they will buy hundreds of TB of SAS-based racks in the next few
> years, and they will learn the hard way that Linux does not even see
> them as disks, it will be too late to give my preferred OS a second
> chance.

Hardly.  SAS support is coming, whether from Adaptec or someone else.


> Having read the discussion from the start here a few days ago, I
> believe that Luben maybe has not explained well to non-competent
> people like me what the goal of his work is. I've looked at the GIF
> on T10.org, but I think that the equivalent with what it currently
> implemented in Linux would be worth doing. Maybe we would even
> notice that current maintainers cannot agree on a same representation.

The current maintainers seem to agree on the path to transport independence.


> Anyway Luben, I fear that for some time, you'll have to provide
> pre-patched sources as well as binary kernels to enterprise customers
> who still try to get Linux working in production. I hope that this sad
> experience will not discourage other vendors from trying to take the
> opensource wagon, as it clearly brings fuel to closed-source drivers
> at the moment (no need to argue).

Yes, let's not argue this silliness.  Other vendors don't seem to have 
this level of problem.


> Eventhough I don't have SAS, I sincerely hope that a quick and smart
> solution will be found which keeps everyone's pride intact, as it
> seems to matter much those days. In an ideal situation, 2.7 would
> have been opened for a long time, and Luben's code would have been
> discussed to death as a new development needed to be merged before
> 2.8. Right now, as 2.7 is 2.6.<odd>, probably that ideas can gem
> before 2.6.15.

Sigh.  This is not about pride.  There's already a path to fixing up the 
SCSI core to work nicely with SAS (and nicer with FC/iSCSI).  Changing 
to a new path midstream, in the middle of addressing the stated 
problems, causes more delay, more harm than good.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> 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.

How many times do we have to repeat "HCIL dependencies should get moved 
to SPI-specific transport code" before you listen?


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

Quit being silly.  I meant what I wrote.  Though it turns out that your 
interpretation of James's ideas was incorrect.  James agrees that 
"transport code" includes both lib and attributes, not attributes only.


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

By focusing on attributes, you miss the big picture.  This is not about 
attributes.


> 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).

This is fundamental:  SCSI specs dictate how this functions, not 
necessarily what Linux code looks like.

The big picture is

	device class <-> transport class

and everything falls out from there, including SAM.

Moving SPI (parallel SCSI, for those unfamiliar with the acronym) to 
transport-specific code will eliminate legacy assumptions that you keep 
complaining about.

Linux is about getting things done, not being religious about 
specifications.  You are way too focused on the SCSI specs, and missing 
the path we need to take to achieve additional flexibility.

With Linux, it's all about evolution and the path we take.


> 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 long as you think James is merely talking about attributes, you're 
just not getting it.

Transport classes are an abstraction which allows SAS to exist as a peer 
to parallel SCSI, FC, and other acronyms.


>>>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".

I mean, paying too much attention to specs at the expense of 
understanding how Linux code needs to be shaped.


>>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".

They are asking you to help with the task of eliminating SPI 
dependencies in the core, so that SAS can exist as a peer to other 
transports.


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

Repeating myself (and others):  everybody wants HCIL stuff to move to 
SPI-specific transport code.

That is the task that must be completed BEFORE transport layer for SAS 
can be fully merged.


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

For the nth time, everybody agrees HCIL should move to 
transport-specific code.

And from past threads, everybody seems OK with moving to a 64-bit lun 
representation.


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

For the nth time: 
http://marc.theaimsgroup.com/?l=linux-scsi&m=112487476527470&w=2

	Jeff

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

[Andre Hedrick]

On Wed, 28 Sep 2005, Luben Tuikov wrote:

> On 09/28/05 15:45, Andre Hedrick wrote:
> > Luben, I have a vested interest in seeing SAS run via SCSI.  So this means
> > you have one ex-demi-god from the world of maintainers looking to pull you
> > have towards the current path and open to ideas and willing to back a
> > better design and push it.
> 
> Ok, thanks Andre.  Much appreciated.

Luben,

I have a vested interest in the improvement of the Linux SCSI Core and
wider adoption and support for SATA II and SAS controllers with their
associated domains and transport.

> You are the first person to back me up _publicly_.  Now if we
> can find a person from "the community" to do that, and get all
> the other people who've written me _privately_, we'd be in
> good shape.

Proving a better design with a migration path for integration is the key
for success; however, I am not the person to be the political voice in the
process.  People will disagree in the process and the only counter to
remove blockage/adoption is in code.

James is king of the hill, and is reasonable to a point.  James also
follows a model of generalization v/s specific design.  Argh, this is not
going to be an easy one to explain or back away from now.  Erm, inclusive
API design is where I am wanting to go with this thought.

Have you and company considered the approach of mapping to a library of
sorts?

Cheers,

Andre

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

[Willy Tarreau]

Hi all, hi Luben,

On Wed, Sep 28, 2005 at 04:56:20PM -0400, Luben Tuikov wrote:
(...)
> Ok, thanks Andre.  Much appreciated.
> 
> You are the first person to back me up _publicly_.  Now if we
> can find a person from "the community" to do that, and get all
> the other people who've written me _privately_, we'd be in
> good shape.

I'm sure I'm not one of those who qualify best here, but having largely
contributed to Linux acceptance at critical points at a handful of big
customers here, I'd like to send some general feeling I get from there.

There are people buying expensive hardware. The type of hardware
that costs $100k for just a few CPUs. Those people don't buy "the
Adaptec XXX which runs best with Red Hat Enterprise" nor the "LSI
YYY which runs best with Solaris", they buy a few $100k systems
with 3 TB disk to store their monthly logs. They cannot even imagine
that the hardware in the $100k system will not be fully supported by
some recent OS, that's just plain silly. The OS cost is just a water
drop in the middle of this. When they install Solaris on it because
they're used to run it, it just works. When I sometimes just show
them that Solaris is not adequate for daily greps in logs, and I show
them how faster it is on a $1k Linux machine in the next rack, they
feel they can switch to it easily. But if they discover that this
system does not correctly support their $100k hardware, do you know
which one was is the crap ? the $300 Red Hat or the $100k hardware ?
[ oh, BTW, I forgot to tell you : they say "Red Hat", and not "Linux"
because it does not sound like what they long considered an OS for
tamagotchis - to use their own words - :-( ]

And when they go to adaptec site to find latest drivers and they only
find patches which forces them to find another Linux to install the
sources and guess how to patch and build, do you know which OS they
consider as hobbyist's ? The Red Hat ! (which they can call "Linux"
again then).

For those reasons, I could put Linux there on very specific places,
mostly firewalls and load-balancers. A self-made distro with kernel
2.4 with patch-o-matic still is one of the most powerful and reliable
firewalls around, and at only a few bucks. The same hardened install
is used for load-balancers with my proxy. Seeing that the proxies
have been stable for years, they bought between 50-100 RHEL licences.
But that's all. Nowhere you will find anything serious using Linux in
other areas. It's already a nightmare for them to get a hardware RAID
card working while they just have to click on stupid icons in Windows
to do the same. Right now, new Linux-based machines are turning back
to plain IDE. SCSI was too much boring for them and not needed to do
just networking. Period.

When they will buy hundreds of TB of SAS-based racks in the next few
years, and they will learn the hard way that Linux does not even see
them as disks, it will be too late to give my preferred OS a second
chance.

Hans Reiser once said that every software needs a complete rewrite
every 3 or 5 years (I don't precisely remember). I tend to agree
with him. Maybe it's time to completely rewrite the SCSI subsystem,
but maybe it will be too long, too risky and not worth the effort.
Maybe it can simply coexist with another new subsystem. This is what
Luben seems to have done : break no code, just bring a new subsystem
which should not even give the SCSI maintainer too much work if he
maintains it himself. At least I could understand some arguments against
Reiser4 because it touched the VFS, but here we have a perfect example
of something new which can live next to SCSI and probably some time
will replace it definitely. Jeff has done this with libata (it even
had to touch some pieces to coexist with piix4 and probably a few other
chips).

Having read the discussion from the start here a few days ago, I
believe that Luben maybe has not explained well to non-competent
people like me what the goal of his work is. I've looked at the GIF
on T10.org, but I think that the equivalent with what it currently
implemented in Linux would be worth doing. Maybe we would even
notice that current maintainers cannot agree on a same representation.
Maybe it will enlighten some of us about the poor error reporting,
the reasons why USB storage sometimes fails to assign a device when
plugging a flash, etc...

Luben, you seem to have enough knowledge to draw both diagrams
side-by-side :
 - the T10 spec with colors on the boxes covered by your work
 - the Linux view of SCSI

Perhaps we will see that current code can be extended without too
much work, or perhaps we will see that it's definitely a dead end
and that a new design will help a lot.

Anyway Luben, I fear that for some time, you'll have to provide
pre-patched sources as well as binary kernels to enterprise customers
who still try to get Linux working in production. I hope that this sad
experience will not discourage other vendors from trying to take the
opensource wagon, as it clearly brings fuel to closed-source drivers
at the moment (no need to argue).

Eventhough I don't have SAS, I sincerely hope that a quick and smart
solution will be found which keeps everyone's pride intact, as it
seems to matter much those days. In an ideal situation, 2.7 would
have been opened for a long time, and Luben's code would have been
discussed to death as a new development needed to be merged before
2.8. Right now, as 2.7 is 2.6.<odd>, probably that ideas can gem
before 2.6.15.

Just my personnal thoughts
Willy

PS: please don't CC me in return, I can read LKML. I haven't trimmed
the CC list as nobody has complained yet.

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

[Moore, Eric Dean]

On Wednesday, September 28, 2005 10:59 AM, Luben Tuikov wrote:
> On 09/28/05 11:15, Moore, Eric Dean wrote:
> > Luben: I guess you didn't get what I meant.
> > 
> > I was referring that there are other
> > *vendors* (not LSI, e.g MegaRAID) that are 
> > working on sas solutions with sas firmware 
> > implementation. One that comes to mind is
> > Intel SunRise Lake, which is non a MPT based 
> > solution, that would work with Christophs 
> > Sas Layer. There maybe others, such as emulex.
> > Perhaps James S. could comment on that.
> 
> This means that they have an IOP on the same
> silicone or on the same packaging.
> 
> This means, again that they'd done all transport
> specific tasks in the FW (by the IOP).
> 

Can you stop this tirade, e.g. conspiracy theory,
in regards to LSI/MPT and the transport layer?
That is not the case.   There will be other sas 
solutions that implement discovery, and 
sas/sata translation in firmware, higher level
event handling.
  

> Again, such solutions do _not_ need the
> SAS Transport Layer.
> 
> They don't even need the attributes, but
> as a "nice to have" feature, you can use
> transport attributes.

Have you forgotten about CSMI/SDI?  It was
nearly a year ago I got blasted when I posted
a sas driver with all those IOCTLs.  CSMI/SDI
is more than a "nice to have" feature.
Its taken quite a bit of time(and greif)
to re-design the driver so it will work with
the transport layers in the way people on this
forum wanted it. Trust me, its been painful.

> 
> You, as technical person, should recognize
> the different needs and thus the different
> solutions between LSI's implementation and
> Adaptec's.
> 
> I'm surprised you never chimed in in defense
> of the _different_ technology.
> 
> See, I've mentioned many times that the two
> radically different technologies can coexist.
> But I've not heard any technical word
> from the other guys: you.
> 

I just don't have time to engage you.
I've got work to do, customer requests, issues,
etc.

Eric Moore

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

[Luben Tuikov]

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

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

[Jeff Garzik]

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.


> Jeff, would you be accepting patches?

Yes.  That's what I mean when I say "submit patches".


>>>No, not true.  It _integrates_ with SCSI Core.  The sad truth
>>>is that SCSI Core knows only HCIL.
>>
>>
>>That's something that needs fixing, for SAS.
> 
> 
> Would you be accepting patches for the creation,
> and use of "struct scsi_domain_device { ... }"?
> 
> This would be a "SCSI Device with a Z Port".
> Z could be target or initiator (most likely just T).
> 
> Then for each scsi_domain_device, SCSI Core does
> REPORT LUNS and then INQUIRY for each LU it found.
> 
> The old (current) code would still say as is, unchanged,
> since it supports older, broken hardware.
> 
> Would you be accepting patches for this?

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.


>>>I repeat again that I had this code _long_ before Christoph
>>>ever dreamt up SAS.  And he got my code via James B sometime
>>>before OLS this year.  I think he got it July 12, 2005.
>>>
>>>The question is: why didn't _he_ use the solution already
>>>available?
>>
>>
>>Because it has the problems listed time and again.
> 
> 
> What problems when there was no other code around.
> 
> Look at it this way: _their_ code doesn't integrate
> with ours.  See?
> 
> I simply cannot take an argument like this:
>    "Because it has the problems listed time and again."
> 
> You have to be specific.

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


>>The SAS transport class is designed to support both firmware-based 
>>devices like MPT, and non-firmware devices such as Adaptec.
> 
> 
> No, it never has been.  It is an _attribute_ exporting framework
> only.
> 
> If you understood how different those architectures are,
> you'd understand what I mean.

James is wrong here.  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 
will share this transport code, but not necessarily all SAS 
implementations (MPT, qla etc.).


>>Sure it might need patches -- send patches, work with people, rather 
>>than ignoring existing work.
> 
> 
> 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.


> Exporting attributes from MPT-based drivers is not the same
> as managing a transport.
> 
> I repeat again:
>   * MPT _hides_ the transport and the managment
>     of the transport from you -- so in effect there is
>     nothing to manage.
>   * MPT gives you Logical Units to work with, NOT ever domain
>     devices or anyhing domain like.
>   * MPT gives you a SAM/SPC hook to hook _right_ into SCSI Core.
> 
> _This_ is why their LLDD _can_ use the host template.
> 
> 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.


> To convince yourself of this: take a look at the _members_ of
> the scsi host/scsi host template: nothing in that structure is
> presented in the chip -- UNLIKE old Parallel SCSI device drivers.
> 
> The scsi host template was written to cater to _old_ (then new)
> Parallel SCSI drivers!  Times have changed!  Time to evolve.

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


>>We've been over the technical stuff time and again.  That's the 
>> maintainer problem. 
> 
> 
> No we haven't been over the technical stuff time and again.
> 
> 
>>We need someone who will listen to the community.
> 
> 
> I bet you're melting people's hearts when they read this.
> 
> So to summarize for corporate management what you're saying
> here is:
>   - you're saying that I do not listen to "the community",

correct


>   - you're saying that I'm an _outsider_ to "the community",

irrelevant


>   - you're saying that I'm no good to work with you, since
>     you are part of that community but not me.

irrelevant


> That is you cannot take it that someone will tell 
> "the community" anything.  "The community" knows all and it
> knows best.
> 
> So in effect there are no good and knowlegable engineers
> anywhere but in the "Linux community".
> 
> That is there is no people with new ideas, better ideas,
> innovative ideas, more knowlege about certain subject matter,
> _anywhere_ but in the "Linux community".
> 
> So in effect, there will never be an "outsider" who will
> come in to the "linux community" and change things around,
> no fresh ideas, no better (right?) way to do things.
> 
> "The community" is not going to listen to anyone but only to
> already politically established members on _any_ subject
> matter, even technical, even from "outsiders" who work with
> the technology every day.

overreaction


>>>What _exactly_ does it mean "don't play well with others"?
>>
>>
>>It means not taking feedback, and working around rather than with the 
>>SCSI core.
> 
> 
> So does this mean, that if I submit patches "fixing" (oops,
> not meant to hurt anyone's bal^w^w^wpride) SCSI Core, they
> will be accepted.

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


> Or do you want me to do "your way of SAS"?
> Maybe JB et al, should write the "Linux SAS spec" and
> then we can recommend this to T10.org, so they can scrap
> their version and use "the community's"?

You're over-reacting.


>>Then you don't understand the ->qc_{prep,issue} hooks.  That should get 
>>you 90% of the way there, if not 99%.
> 
> 
> But I have to simulate struct ata_port, Jeff.
> 
> Which isn't so bad, but speaks about the design.

You have to provide a means to submit ATA commands and receive results, 
no more or less.


>>>The code doesn't alter Linux SCSI or anyone else's behaviour.
>>>It only _provides_ SAS support to the kernel.

>>That's one of the problems: It should update the SCSI core.

> Thank you for admitting this -- you're the first and only
> member of "the community" (since I'm not a member apparently)
> to admit this.

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

You need to update the SCSI core properly, rather than working around it.

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

	Jeff

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

[Luben Tuikov]

On 09/28/05 15:45, Andre Hedrick wrote:
> Hi Patrick,
> 
> You have hit on one of the key word of my downfall.
> 
> Specifications!!!
> 
> I believe in them and they are the inflexable state machine which all OSes
> are required to address.

Me too.  I live and breathe by them.

> I am for following the rules of the spec, and will bet Linus would now
> agree more so than before.

Me too.

An interesting thing which "the community" would appreciate is
that M$ has aggressively started to "go by the spec" as far
as SCSI is concerned.

Ding-ding!

> The problem is SCSI is a strange beast without
> a formal FSM.  It is more of a BusPhase psuedo stated transport.  It is

Oh, no, no, no!  So much has changed Andre.

Just take a look at SAM, and I'm sure that you'll appreciate the object
oriented design, the abstractions, etc.  Really!

Recently all new protocols follow _explicit_ state machine definitions
at each layer they define, and how it interacts with the layer
above and below again by FSMs.  It's all a good thing.

> Luben, I have a vested interest in seeing SAS run via SCSI.  So this means
> you have one ex-demi-god from the world of maintainers looking to pull you
> have towards the current path and open to ideas and willing to back a
> better design and push it.

Ok, thanks Andre.  Much appreciated.

You are the first person to back me up _publicly_.  Now if we
can find a person from "the community" to do that, and get all
the other people who've written me _privately_, we'd be in
good shape.

	Luben
P.S. Not sure if you have seen this link:
http://linux.adaptec.com/sas/

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

[Luben Tuikov]

On 09/27/05 22:02, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>On 09/27/05 17:55, Jeff Garzik wrote:
>>
>>
>>>* Avoids existing SAS code, rather than working with it.
> 
> 
>>No, it's the _other_ way around.  There is NO existing
>>SAS code.
> 
> 
> Incorrect, just look in the latest upstream kernel.

Yes, because it was Christoph's code submitted right after
I submitted and JB took his code right in.

Again, I had the infrastructure ready _before_ OLS.

> libata-scsi.c is the SAT translation layer.

Not quite.

It has potential to become SATL but at its current
form it cannot be:

int ata_scsi_queuecmd(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
{
	struct ata_port *ap;
	struct ata_device *dev;
	struct scsi_device *scsidev = cmd->device;

	ap = (struct ata_port *) &scsidev->host->hostdata[0];

If I want to use that I have to _simulate_ ata_port.
Furthermore, scsidev->host->hostdata may not point
to ata_port for SATA devices over a different transport.

Ideally SATL is just a _data transformation function_ and
getting to the ATA device is transport dependent.

Jeff, would you be accepting patches?

>>No, not true.  It _integrates_ with SCSI Core.  The sad truth
>>is that SCSI Core knows only HCIL.
> 
> 
> That's something that needs fixing, for SAS.

Would you be accepting patches for the creation,
and use of "struct scsi_domain_device { ... }"?

This would be a "SCSI Device with a Z Port".
Z could be target or initiator (most likely just T).

Then for each scsi_domain_device, SCSI Core does
REPORT LUNS and then INQUIRY for each LU it found.

The old (current) code would still say as is, unchanged,
since it supports older, broken hardware.

Would you be accepting patches for this?

>>I repeat again that I had this code _long_ before Christoph
>>ever dreamt up SAS.  And he got my code via James B sometime
>>before OLS this year.  I think he got it July 12, 2005.
>>
>>The question is: why didn't _he_ use the solution already
>>available?
> 
> 
> Because it has the problems listed time and again.

What problems when there was no other code around.

Look at it this way: _their_ code doesn't integrate
with ours.  See?

I simply cannot take an argument like this:
   "Because it has the problems listed time and again."

You have to be specific.

> The SAS transport class is designed to support both firmware-based 
> devices like MPT, and non-firmware devices such as Adaptec.

No, it never has been.  It is an _attribute_ exporting framework
only.

If you understood how different those architectures are,
you'd understand what I mean.

> Sure it might need patches -- send patches, work with people, rather 
> than ignoring existing work.

I do not _know_ how to consolidate the completely broken
"design" set forth by JB and company.

It is _completely_ not to SAM spec.

Exporting attributes from MPT-based drivers is not the same
as managing a transport.

I repeat again:
  * MPT _hides_ the transport and the managment
    of the transport from you -- so in effect there is
    nothing to manage.
  * MPT gives you Logical Units to work with, NOT ever domain
    devices or anyhing domain like.
  * MPT gives you a SAM/SPC hook to hook _right_ into SCSI Core.

_This_ is why their LLDD _can_ use the host template.

But an AIC-94xx and BCM8603 _is_ NOT a scsi_host material.  It is just
an interface to the interconnect.

To convince yourself of this: take a look at the _members_ of
the scsi host/scsi host template: nothing in that structure is
presented in the chip -- UNLIKE old Parallel SCSI device drivers.

The scsi host template was written to cater to _old_ (then new)
Parallel SCSI drivers!  Times have changed!  Time to evolve.

> We've been over the technical stuff time and again.  That's the 
>  maintainer problem. 

No we haven't been over the technical stuff time and again.

> We need someone who will listen to the community.

I bet you're melting people's hearts when they read this.

So to summarize for corporate management what you're saying
here is:
  - you're saying that I do not listen to "the community",
  - you're saying that I'm an _outsider_ to "the community",
  - you're saying that I'm no good to work with you, since
    you are part of that community but not me.

That is you cannot take it that someone will tell 
"the community" anything.  "The community" knows all and it
knows best.

So in effect there are no good and knowlegable engineers
anywhere but in the "Linux community".

That is there is no people with new ideas, better ideas,
innovative ideas, more knowlege about certain subject matter,
_anywhere_ but in the "Linux community".

So in effect, there will never be an "outsider" who will
come in to the "linux community" and change things around,
no fresh ideas, no better (right?) way to do things.

"The community" is not going to listen to anyone but only to
already politically established members on _any_ subject
matter, even technical, even from "outsiders" who work with
the technology every day.

>>What _exactly_ does it mean "don't play well with others"?
> 
> 
> It means not taking feedback, and working around rather than with the 
> SCSI core.

So does this mean, that if I submit patches "fixing" (oops,
not meant to hurt anyone's bal^w^w^wpride) SCSI Core, they
will be accepted.

Or do you want me to do "your way of SAS"?
Maybe JB et al, should write the "Linux SAS spec" and
then we can recommend this to T10.org, so they can scrap
their version and use "the community's"?

I hear there was such a suggestion on the mailing lists
for ATA and T13.org, but I'm sure I'm misunderstanding
something here as usual.

> Then you don't understand the ->qc_{prep,issue} hooks.  That should get 
> you 90% of the way there, if not 99%.

But I have to simulate struct ata_port, Jeff.

Which isn't so bad, but speaks about the design.

>>What you need to do is to write a SATL layer, just as you can
>>see in SAT-r6, page 2, Figure 3.  I'm on top of this already.
> 
> Re-read libata-scsi.c, and submit any patches you feel are needed.

Will do.

>>The code doesn't alter Linux SCSI or anyone else's behaviour.
>>It only _provides_ SAS support to the kernel.
> 
> 
> That's one of the problems: It should update the SCSI core.

Thank you for admitting this -- you're the first and only
member of "the community" (since I'm not a member apparently)
to admit this.

	Luben

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

[Andre Hedrick]

Hi Patrick,

You have hit on one of the key word of my downfall.

Specifications!!!

I believe in them and they are the inflexable state machine which all OSes
are required to address.  Linux has a very bad history of avoiding the
boundary conditions related to storage.

I am for following the rules of the spec, and will bet Linus would now
agree more so than before.  The problem is SCSI is a strange beast without
a formal FSM.  It is more of a BusPhase psuedo stated transport.  It is
smart enough to laugh at bad software designs and keep going.  Sheesh,
look at M$'s miniport.

This leads me to a point where a similar (but smarter) miniport could look
interesting.  However, this is also where the transport classes have their
bases, afaics.  Anyone please correct me where I have mistated (other than
Linus, :-p).

Luben, I have a vested interest in seeing SAS run via SCSI.  So this means
you have one ex-demi-god from the world of maintainers looking to pull you
have towards the current path and open to ideas and willing to back a
better design and push it.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 28 Sep 2005, Patrick Mansfield wrote:

> On Wed, Sep 28, 2005 at 04:37:03AM -0700, Luben Tuikov wrote:
> 
> > never ever going in.  Why else do you think IBM-ers agree with him that
> > Linux SCSI doesn't need 64 bit LUNS?
> 
> Please stop repeating that, no one said we should *not* implement a 64 bit
> LUN in linux scsi, and James posted a patch for 64 bit LUN. I posted a
> clarification in response to your earlier postings, you seem to have
> ignored or forgotten this post:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112671847228275&w=2
> 
> I said:
> 
> "I am talking about the scsi spec, not the code. IMO linux scsi code
> should support W_LUN and 64 bit LUN."
> 
> -- Patrick Mansfield
> -
> 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/
> 

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

[Luben Tuikov]

On 09/28/05 12:30, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 28 Sep 2005 04:37:03 PDT, Luben Tuikov said:
> 
> 
>>When it comes down to it SCSI Core is 20 years behind and thus Linux Storage
>>is 20 years behind.
> 
> 
> Hmm.. 20 years ago I was hooking Fujitsu Super-Eagles to Sun3/280 servers.
> If you're going to claim that the current SCSI core is *that* far behind, you're
> going to have to back it up.  Remember that making exaggerated claims is a good
> way to make people not listen to the *rest* of your message.
> 
> Seen in include/scsi/scsi.h:
> 
>         /*
>          * FIXME: bit0 is listed as reserved in SCSI-2, but is
>          * significant in SCSI-3.  For now, we follow the SCSI-2
>          * behaviour and ignore reserved bits.
>          */
> 
> So obviously, it's at least the number of years since SCSI-3 was defined,
> but no more than the time since SCSI-2.  According to http://home.comcast.net/~SCSIguy/SCSI_FAQ/scsifaq.html
> SCSI-2 devices started showing up in 1988, and X3.131-1994 came out in 1994.
> 1996 saw the first SCSI-3 proposals.
> 
> I'll give you *one* decade, but not two. :)

Ok, I'll take that.

BTW, I was referring to the _architecture_ of SCSI Core.

It hasn't seen any _innovation_ for the last 5 years
as far as SCSI or Storage is concerned.

	Luben

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

[Luben Tuikov]

On 09/28/05 12:27, Patrick Mansfield wrote:
> On Wed, Sep 28, 2005 at 04:37:03AM -0700, Luben Tuikov wrote:
> 
> 
>>never ever going in.  Why else do you think IBM-ers agree with him that
>>Linux SCSI doesn't need 64 bit LUNS?
> 
> 
> Please stop repeating that, no one said we should *not* implement a 64 bit
> LUN in linux scsi, and James posted a patch for 64 bit LUN. I posted a
> clarification in response to your earlier postings, you seem to have
> ignored or forgotten this post:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=112671847228275&w=2

Sorry.

I was refering to the bottom of this email:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112665156918643&w=2

	Luben

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

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Wed, 28 Sep 2005 04:37:03 PDT, Luben Tuikov said:

> When it comes down to it SCSI Core is 20 years behind and thus Linux Storage
> is 20 years behind.

Hmm.. 20 years ago I was hooking Fujitsu Super-Eagles to Sun3/280 servers.
If you're going to claim that the current SCSI core is *that* far behind, you're
going to have to back it up.  Remember that making exaggerated claims is a good
way to make people not listen to the *rest* of your message.

Seen in include/scsi/scsi.h:

        /*
         * FIXME: bit0 is listed as reserved in SCSI-2, but is
         * significant in SCSI-3.  For now, we follow the SCSI-2
         * behaviour and ignore reserved bits.
         */

So obviously, it's at least the number of years since SCSI-3 was defined,
but no more than the time since SCSI-2.  According to http://home.comcast.net/~SCSIguy/SCSI_FAQ/scsifaq.html
SCSI-2 devices started showing up in 1988, and X3.131-1994 came out in 1994.
1996 saw the first SCSI-3 proposals.

I'll give you *one* decade, but not two. :)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

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

[Patrick Mansfield]

On Wed, Sep 28, 2005 at 04:37:03AM -0700, Luben Tuikov wrote:

> never ever going in.  Why else do you think IBM-ers agree with him that
> Linux SCSI doesn't need 64 bit LUNS?

Please stop repeating that, no one said we should *not* implement a 64 bit
LUN in linux scsi, and James posted a patch for 64 bit LUN. I posted a
clarification in response to your earlier postings, you seem to have
ignored or forgotten this post:

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

I said:

"I am talking about the scsi spec, not the code. IMO linux scsi code
should support W_LUN and 64 bit LUN."

-- Patrick Mansfield

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

[Linus Torvalds]

On Wed, 28 Sep 2005, Matthew Wilcox wrote:
> 
> Dude, that document is written in a very tongue-in-cheek style.

True, true. But sometimes you can say painful truths more easily if you do 
it as a joke. Most of the ManagementStyle document is perfectly valid.

Whether it has any bearing on this discussion is another matter ;)

		Linus

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

[Matthew Wilcox]

On Wed, Sep 28, 2005 at 04:37:03AM -0700, Luben Tuikov wrote:
> Yes, and I think you'll agree with me, the Maintainer isn't/shouldn't
> necessarily be the person "defining direction".  The reasons are
> many but mostly:
>   * Documentation/ManagingStyle document (valuable read),
> That document _really_ says it _all_.  I suggest all developers, maintainers,
> and corporate _management_ reading this thread to read it.

Dude, that document is written in a very tongue-in-cheek style.  There's
a few clues:

"the preferred (or made up, depending on who you ask) management style"

"this document may or may not have anything to do with reality.  It
 started as a lark"

It's really not a club for you to beat James with.

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

[Luben Tuikov]

--- "Moore, Eric Dean" <Eric.Moore@lsil.com> wrote:

> On Tuesday, September 27, 2005 4:51 PM, Luben Tuikov wrote:
> 
> > Christoph's code is
> >  * MPT based only,
> >  * doesn't follow a spec to save its life,
> >  * far inferior in SAS capabilities and SAS representation
> >    again, due to the fact that it is MPT based.
> > 
> > Since the whole point of MPT is to _hide_ the transport.
> > 
> 
> 
> Hi Luben,
> 
> OK, Man are you alright?
> 
> I've heard of other vendors planning to 
> provide solutions where sas is implemented
> in firmware, similar to MPT.  Christophs
> sas layer is going to work with other 
> solutions, don't think of it being 
> MPT centric.

Where in what I said above do I say that it will _not_
work with _other_ MPT based drivers?  Nowhere!

Yes it _will_ work with other MPT-like drivers but
to cut and paste again from above:
 * MPT based only,
 * doesn't follow a spec to save its life,
 * far inferior in SAS capabilities and SAS representation
   again, due to the fact that it is MPT based.

When I say MPT, I do not mean MPT(R), I mean MPT as
in technology, not as in trademark.

     Luben

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

[Luben Tuikov]

Hi Andre,

--- Andre Hedrick <andre@linux-ide.org> wrote:
> From what I know from history and why I no longer maintain anything,
> (working to get sanity back) is the Maintainer defines direction while
> following a bigger picture.

Yes, and I think you'll agree with me, the Maintainer isn't/shouldn't
necessarily be the person "defining direction".  The reasons are
many but mostly:
  * Documentation/ManagingStyle document (valuable read),
That document _really_ says it _all_.  I suggest all developers, maintainers,
and corporate _management_ reading this thread to read it.

Why should the Maintainer be "defining direction"?  Is this some
religous cult where "Beaver knows best?" (punt intended!)
Or is this a theocratic society here at Linux SCSI? "Pi = 3" ;-)

The maintainership role is and has been _clearly_ defined!  For the
sake of eveyone else, take a look at 2.4 maintainer, 2.6 maintainer,
other subsystem maintainers: defined by example and in word.
So much unlike SCSI Core.

Another also great reason is:
  * Complete, utter and infinite _incompetence_ coupled with too much pride.
It hurts us all.

When it comes down to it SCSI Core is 20 years behind and thus Linux Storage
is 20 years behind.

> Help create a better lie by mapping into the design set forward by James
> and company.  If the goal of Adaptec is to have support then they need to

Yes, this is indeed a very valuable advice.  I hadn't ever looked at it
like that.

What I thought, albeit erroneously, mea culpa, is that Linux actually
_wanted_ to be "the storage OS of choice".  Now I see and realize that
due to neglected management, Linux has very little to do with _storage_.

Linux need to thank the mutitude of storage ignorant customers
willing to pay the buck, because it is _Linux_ (put gasping sound here).

Linux _can_ be the "storage OS of choice", but this will not happen
through neglect, or sheer incompetence coupled with lots of pride.

Back on topic: I'll try to keep up this "Linux storage lie" set forth
by the james-bottomleys of the Linux community.

> buckup and play be to rules at hand.  Remember, most people are open to
> new ideas and better models.  Propose one and you will find backing.

I never have found backing.  It is all in the archives of linux-scsi
mailing list.  What happens is that even if people like your idea
and write to you _privately_ to tell you that they like your
idea, somewhere in their email, they tell you not to cross-post
their message to the list because they have storage products which
need Linux.  The reason for this is that James Bottomley has established
this politics that if you don't agree to his antics, your patches are
never ever going in.  Why else do you think IBM-ers agree with him that
Linux SCSI doesn't need 64 bit LUNS?

_But_ I'm willing to try _again_.  So I'll be proposing something
later this morning.  (You know, all engineers are optimists.)

       Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/27/05 18:01, Jeff Garzik wrote:
>>Just follow the recipe Christoph outlined.  It's not difficult, just 
>>requires some work.
> 
> 
> Anyone have a clear technical plan and/or infrastructure
> on how to do this?  Any specs, plans, consolidations, etc?

Yes, read Christoph's todo list.

We need to separate out bits specific to parallel SCSI, moving the bits 
to transport-specific code, since SAS doesn't need them.


>>It does an end run around 90% of the SCSI core.  You might as well make 
>>it a block driver, if you're going to do that.
> 
> 
> The "90%" part isn't quite true.
> 
> But going with a block device isn't that bad:
> Now since the architecture _is_ SCSI after all, what would be
> needed is a minimal, fast, straightforward, SAM/SPC fully complient
> new SCSI Core.  That SCSI Core would register block devices
> with the block layer.  Maybe Jens can point out cool things
> to do and make the whole infrastructure fast and very fast.
> (since we don't need to be bound by this legacy stuff)
> 
> Essentially other new technology LLDD and Transport layers
> can probably make use of this: Infiniband, USB2 Storage, etc.
> 
> So if all you have is an AIC-94xx or BCM8603 storage chip
> you can exclule all of the legacy SCSI Core and compile this
> new mean, lean, fast SAM Core.
> 
> Jeff, this isn't bad at all!
> 
> Are you willing to contribute to such an effort?

No.  I'm much more willing to help integrate aic94xx and 
Broadcom/ServerWorks into the existing SCSI core, working with the 
community.

As Andrew guessed, it's a way to get you your own playpen, where you 
won't be constrained by members of the Linux-SCSI community.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> On 09/27/05 17:55, Jeff Garzik wrote:
> 
>>* Avoids existing SAS code, rather than working with it.

> No, it's the _other_ way around.  There is NO existing
> SAS code.

Incorrect, just look in the latest upstream kernel.


>>* Avoids existing SATA code, rather than working with it.
> 
> 
> FUD!  Why?  It does _not_ use SATA code at all.

That's the problem.


> Why?  SATA devices are discovered on the domain, but
> there is _no_ SATL in the kernel to represent them.
> 
> And libata is _not_ SATL.  The reasons are that

libata-scsi.c is the SAT translation layer.


>>* Avoids (rather than fix) several SCSI core false dependencies on HCIL. 
>>  Results in code duplication and/or avoidance of needed code.
> 
> 
> No, not true.  It _integrates_ with SCSI Core.  The sad truth
> is that SCSI Core knows only HCIL.

That's something that needs fixing, for SAS.


> I repeat again that I had this code _long_ before Christoph
> ever dreamt up SAS.  And he got my code via James B sometime
> before OLS this year.  I think he got it July 12, 2005.
> 
> The question is: why didn't _he_ use the solution already
> available?

Because it has the problems listed time and again.


> You have to understand the differences between MPT and open
> transport architecture.
> 
> At some point I thought Christoph seemed to have understood it.
> Now I'm not sure any more.
> 
> Now since the open transport solution completely encompasses
> and _absolves_ MPT, it is not hard for an MPT driver to
> generate a bunch of events and use that infrastructure.

The SAS transport class is designed to support both firmware-based 
devices like MPT, and non-firmware devices such as Adaptec.

Sure it might need patches -- send patches, work with people, rather 
than ignoring existing work.


>>* Maintainer reminds me of my ATA mentor, Andre Hedrick:  knows his 
>>shit, but has difficulties working with the community.  May need a 
>>filter if we want long term maintenance to continue.
> 
> 
> I take offence in your liking me to Andre -- I don't know
> Andre personally, but is seems that you're expressing personal
> opinion against him, against me and labeling me in some way.
> 
> I take offence in that, Jeff.
> 
> Why are you making this a _political_ and personal game?
> 
> All you're doing is trying to aliken me to someone and
> brandish me as someone I'm not.
> 
> This is rude, offensive and done in desperation.
> 
> Shall we concentrate on the _technical_ part of
> the argument?
> 
> I repeat again: _technical_ part of the argument.

We've been over the technical stuff time and again.  That's the 
maintainer problem.  We need someone who will listen to the community.


>>Easy path: make Adaptec's solution a block driver, which allows it to 
>>sidestep all the "doesn't play well with others" issues.  Still an 
> 
> 
> What _exactly_ does it mean "don't play well with others"?

It means not taking feedback, and working around rather than with the 
SCSI core.


>>Adaptec-only solution, but at least its in a separate playpen.
> 
> 
> I'm sure James Bottomley will move from SCSI Core to the block
> layer as he did for IDR. hehehe :-)
> 
> And no, it is not Adaptec's only solution.  Your BCM8603 SAS
> LLDD when you write it could use it without any problems.
> 
> 
>>Hard path: Update the SCSI core and libata to work with SATA+SAS 
>>hardware such as Adaptec's.
> 
> 
> Cannot do for libata -- ever.  Why?  You know best: because
> libata uses direct access to the hardware!  There is no
> layered architecture.

Then you don't understand the ->qc_{prep,issue} hooks.  That should get 
you 90% of the way there, if not 99%.


> What you need to do is to write a SATL layer, just as you can
> see in SAT-r6, page 2, Figure 3.  I'm on top of this already.

Re-read libata-scsi.c, and submit any patches you feel are needed.


> The code doesn't alter Linux SCSI or anyone else's behaviour.
> It only _provides_ SAS support to the kernel.

That's one of the problems: It should update the SCSI core.

	Jeff

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

[Andre Hedrick]

Eric,

Luben is in shock.

Jeff hinted Luben and I are similar, and that would scare anyone.

Cheers,

Andre

On Tue, 27 Sep 2005, Moore, Eric Dean wrote:

> On Tuesday, September 27, 2005 4:51 PM, Luben Tuikov wrote:
> 
> > Christoph's code is
> >  * MPT based only,
> >  * doesn't follow a spec to save its life,
> >  * far inferior in SAS capabilities and SAS representation
> >    again, due to the fact that it is MPT based.
> > 
> > Since the whole point of MPT is to _hide_ the transport.
> > 
> 
> 
> Hi Luben,
> 
> OK, Man are you alright?
> 
> I've heard of other vendors planning to 
> provide solutions where sas is implemented
> in firmware, similar to MPT.  Christophs
> sas layer is going to work with other 
> solutions, don't think of it being 
> MPT centric.
> 
> 
> Later,
> Eric Moore 
> -
> 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/
> 

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

[Moore, Eric Dean]

On Tuesday, September 27, 2005 4:51 PM, Luben Tuikov wrote:

> Christoph's code is
>  * MPT based only,
>  * doesn't follow a spec to save its life,
>  * far inferior in SAS capabilities and SAS representation
>    again, due to the fact that it is MPT based.
> 
> Since the whole point of MPT is to _hide_ the transport.
> 


Hi Luben,

OK, Man are you alright?

I've heard of other vendors planning to 
provide solutions where sas is implemented
in firmware, similar to MPT.  Christophs
sas layer is going to work with other 
solutions, don't think of it being 
MPT centric.


Later,
Eric Moore 

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

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

On Tue, 2005-09-27 at 19:03 -0400, Luben Tuikov wrote:
> On 09/27/05 18:01, Jeff Garzik wrote:
> > Luben Tuikov wrote:
> > 
> >>The driver and the infrastructure needs to go in.
> >>
> >>Give it exposure to the people, let people play with it.
> > 
> > 
> > Merging into the upstream kernel is not necessary for exposure.
> > 
> > Historically, saying "no" to a single vendor pushing really hard -- as 
> > you are doing -- has resulted in a superior solution.
> 
> This of course implies that everything in Linux is a
> superiour solution _or_ if it is not, then everything in
> linux is a vendor solution.

Or perhaps that it tends to result in better solutions than what would
exist if every vendor wrote their drivers with no consideration for
other vendors.

> 
> >>If we start "fixing" SCSI Core now (this in itself is JB red
> >>herring), how long before it is "fixed" and we can "rest"?
> >>And how long then before the driver and infrastructure
> >>makes it in?
> > 
> > Just follow the recipe Christoph outlined.  It's not difficult, just 
> > requires some work.
> 
> Anyone have a clear technical plan and/or infrastructure
> on how to do this?  Any specs, plans, consolidations, etc?
> 
> I know its a wishful thinking, but when the architectures
> differ, not sure how to do this.
> "You can do everything with a big long if ()".

This sounds equivalent to "write your own block driver".  

> 
> > So far, this is an Adaptec-only solution.
> 
> Yes, since Adaptec is the first company to come out with
> open transport SAS chip.  Broadcom seems to be doing the same thing.
>  
> > It does an end run around 90% of the SCSI core.  You might as well make 
> > it a block driver, if you're going to do that.
> 
> The "90%" part isn't quite true.
> 
> But going with a block device isn't that bad:
> Now since the architecture _is_ SCSI after all, what would be
> needed is a minimal, fast, straightforward, SAM/SPC fully complient
> new SCSI Core.  That SCSI Core would register block devices
> with the block layer.  Maybe Jens can point out cool things
> to do and make the whole infrastructure fast and very fast.
> (since we don't need to be bound by this legacy stuff)

Except that you would have to re-implement the SCSI upper-layer drivers
(at a minimum). Seems like it would be easier to take the existing code
in your driver/layers and modify to work with the existing SCSI
infrastructure.

> 
> Essentially other new technology LLDD and Transport layers
> can probably make use of this: Infiniband, USB2 Storage, etc.
> 

Seems silly to have all this code duplication.  Why not write to the
existing spec (even if it is an informal one), and then work to get the
spec changed, hopefully without pissing off all the maintainers.

> So if all you have is an AIC-94xx or BCM8603 storage chip
> you can exclule all of the legacy SCSI Core and compile this
> new mean, lean, fast SAM Core.
> 
> Jeff, this isn't bad at all!

I am not sure if Jeff meant this as a tongue-in-cheek suggestion or is
just trying to get you off peoples backs. Perhaps he is indeed
serious.  

Andrew

> 
> Are you willing to contribute to such an effort?
> 
> Thanks,
> 	Luben
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andre Hedrick]

Luben,

Welcome to the club ...

You have managed to prove your knowledge base and forgot everything
learned in kindergarden.  Since I have kids, and spent time back in
kindergarden, there are some valuable lessons there many have forgotten.

>From what I have seen here, both sides have some valid points.

>From what I know from history and why I no longer maintain anything,
(working to get sanity back) is the Maintainer defines direction while
following a bigger picture.

The issues wrt to HCIL v/s WWN v/s Multiplier v/s Target-Mode v/s blahblah
blahblah are important questions.

Remember, everything about storage is a lie.

Help create a better lie by mapping into the design set forward by James
and company.  If the goal of Adaptec is to have support then they need to
buckup and play be to rules at hand.  Remember, most people are open to
new ideas and better models.  Propose one and you will find backing.

Since you are in the bay-area ... want to met who you have been associated
with ... or is the idea to weird?

Cheers,

Andre


On Tue, 27 Sep 2005, Luben Tuikov wrote:

> On 09/27/05 17:55, Jeff Garzik wrote:
> > * Avoids existing SAS code, rather than working with it.
> 
> No, it's the _other_ way around.  There is NO existing
> SAS code.
> 
> My SAS code has been around _long_ before Christophs
> code.
> 
> Christoph's code is
>  * MPT based only,
>  * doesn't follow a spec to save its life,
>  * far inferior in SAS capabilities and SAS representation
>    again, due to the fact that it is MPT based.
> 
> Since the whole point of MPT is to _hide_ the transport.
> 
> > * Avoids existing SATA code, rather than working with it.
> 
> FUD!  Why?  It does _not_ use SATA code at all.
> 
> Why?  SATA devices are discovered on the domain, but
> there is _no_ SATL in the kernel to represent them.
> 
> And libata is _not_ SATL.  The reasons are that
> libata is closely coupled to the hardware, i.e.
> ata_port.
> 
> While in SAS open transport architecures, you'd have
> execute ATA/SAS/SMP task just as you have in aic-94xx.
> Why? Because all the chip is, is an interface to the
> interconect.
> 
> But I'm sure you know all this having looked at the
> specs of BCM8603.
> 
> > * Avoids (rather than fix) several SCSI core false dependencies on HCIL. 
> >   Results in code duplication and/or avoidance of needed code.
> 
> No, not true.  It _integrates_ with SCSI Core.  The sad truth
> is that SCSI Core knows only HCIL.
> 
> Jeff, please be more specific.
> 
> > * So far, it's an Adaptec-only solution.  Since it pointedly avoids the 
> > existing SAS transport code, this results in two SAS solutions in Linux: 
> > one for Adaptec, one for {everyone else}.
> 
> Hmm, again: _architecture_.  And you have to stop these
> accusations: "pointedly avoids the existing SAS transport code".
> 
> I repeat again that I had this code _long_ before Christoph
> ever dreamt up SAS.  And he got my code via James B sometime
> before OLS this year.  I think he got it July 12, 2005.
> 
> The question is: why didn't _he_ use the solution already
> available?
> 
> You have to understand the differences between MPT and open
> transport architecture.
> 
> At some point I thought Christoph seemed to have understood it.
> Now I'm not sure any more.
> 
> Now since the open transport solution completely encompasses
> and _absolves_ MPT, it is not hard for an MPT driver to
> generate a bunch of events and use that infrastructure.
> 
> > * Maintainer reminds me of my ATA mentor, Andre Hedrick:  knows his 
> > shit, but has difficulties working with the community.  May need a 
> > filter if we want long term maintenance to continue.
> 
> I take offence in your liking me to Andre -- I don't know
> Andre personally, but is seems that you're expressing personal
> opinion against him, against me and labeling me in some way.
> 
> I take offence in that, Jeff.
> 
> Why are you making this a _political_ and personal game?
> 
> All you're doing is trying to aliken me to someone and
> brandish me as someone I'm not.
> 
> This is rude, offensive and done in desperation.
> 
> Shall we concentrate on the _technical_ part of
> the argument?
> 
> I repeat again: _technical_ part of the argument.
> 
> > Easy path: make Adaptec's solution a block driver, which allows it to 
> > sidestep all the "doesn't play well with others" issues.  Still an 
> 
> What _exactly_ does it mean "don't play well with others"?
> 
> Do you mean:
>  - the solution is far superiour to anything available now
>  - it presents the SAS Domain in sysfs as it looks in
>    the physical world,
>  - does domain discovery and expander configuration,
>  - allows for complete control of the domain to user space,
>  - it pokes at SCSI Core's 20 year old relics.
>  - it's a thorn in the flesh to other people striving for
>    similar functionality.
> 
> Or do you mean:
>  - it does not change a single line of code in the kernel,
>  - does not break anything existing,
>  - etc, etc.
> 
> > Adaptec-only solution, but at least its in a separate playpen.
> 
> I'm sure James Bottomley will move from SCSI Core to the block
> layer as he did for IDR. hehehe :-)
> 
> And no, it is not Adaptec's only solution.  Your BCM8603 SAS
> LLDD when you write it could use it without any problems.
> 
> > Hard path: Update the SCSI core and libata to work with SATA+SAS 
> > hardware such as Adaptec's.
> 
> Cannot do for libata -- ever.  Why?  You know best: because
> libata uses direct access to the hardware!  There is no
> layered architecture.
> 
> What you need to do is to write a SATL layer, just as you can
> see in SAT-r6, page 2, Figure 3.  I'm on top of this already.
> 
> But in order to do this you need a unified architecture
> for accessing ATA devices.
> 
> Now libata, uses ata_port to do this, which is _hardware_
> access.
> 
> The SAS Transport layer uses Execute SCSI RPC (defined
> in SAM, provided by aic94xx) to do this.
> 
> So in effect, what SATL would end up to be is a
> data transformation function.   But I digress...
> 
> > The hard path takes time, and won't be solved simply by shoving it in.
> 
> No, you can do it now.  It will not affect anyone or anything.
> (Other than hurting a couple of people's pride.)
> 
> The code doesn't alter Linux SCSI or anyone else's behaviour.
> It only _provides_ SAS support to the kernel.
> 
> Including it in as is would does not hurt anyone as you can
> see here:
> http://linux.adaptec.com/sas/git/
> 
> Concentrate on the _technical_ merit, let's be more specific.
> 
> 	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/
> 

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

[Luben Tuikov]

On 09/27/05 18:01, Jeff Garzik wrote:
> Luben Tuikov wrote:
> 
>>The driver and the infrastructure needs to go in.
>>
>>Give it exposure to the people, let people play with it.
> 
> 
> Merging into the upstream kernel is not necessary for exposure.
> 
> Historically, saying "no" to a single vendor pushing really hard -- as 
> you are doing -- has resulted in a superior solution.

This of course implies that everything in Linux is a
superiour solution _or_ if it is not, then everything in
linux is a vendor solution.

>>If we start "fixing" SCSI Core now (this in itself is JB red
>>herring), how long before it is "fixed" and we can "rest"?
>>And how long then before the driver and infrastructure
>>makes it in?
> 
> Just follow the recipe Christoph outlined.  It's not difficult, just 
> requires some work.

Anyone have a clear technical plan and/or infrastructure
on how to do this?  Any specs, plans, consolidations, etc?

I know its a wishful thinking, but when the architectures
differ, not sure how to do this.

"You can do everything with a big long if ()".

> So far, this is an Adaptec-only solution.

Yes, since Adaptec is the first company to come out with
open transport SAS chip.  Broadcom seems to be doing the same thing.
 
> It does an end run around 90% of the SCSI core.  You might as well make 
> it a block driver, if you're going to do that.

The "90%" part isn't quite true.

But going with a block device isn't that bad:
Now since the architecture _is_ SCSI after all, what would be
needed is a minimal, fast, straightforward, SAM/SPC fully complient
new SCSI Core.  That SCSI Core would register block devices
with the block layer.  Maybe Jens can point out cool things
to do and make the whole infrastructure fast and very fast.
(since we don't need to be bound by this legacy stuff)

Essentially other new technology LLDD and Transport layers
can probably make use of this: Infiniband, USB2 Storage, etc.

So if all you have is an AIC-94xx or BCM8603 storage chip
you can exclule all of the legacy SCSI Core and compile this
new mean, lean, fast SAM Core.

Jeff, this isn't bad at all!

Are you willing to contribute to such an effort?

Thanks,
	Luben

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

[Luben Tuikov]

On 09/27/05 17:55, Jeff Garzik wrote:
> * Avoids existing SAS code, rather than working with it.

No, it's the _other_ way around.  There is NO existing
SAS code.

My SAS code has been around _long_ before Christophs
code.

Christoph's code is
 * MPT based only,
 * doesn't follow a spec to save its life,
 * far inferior in SAS capabilities and SAS representation
   again, due to the fact that it is MPT based.

Since the whole point of MPT is to _hide_ the transport.

> * Avoids existing SATA code, rather than working with it.

FUD!  Why?  It does _not_ use SATA code at all.

Why?  SATA devices are discovered on the domain, but
there is _no_ SATL in the kernel to represent them.

And libata is _not_ SATL.  The reasons are that
libata is closely coupled to the hardware, i.e.
ata_port.

While in SAS open transport architecures, you'd have
execute ATA/SAS/SMP task just as you have in aic-94xx.
Why? Because all the chip is, is an interface to the
interconect.

But I'm sure you know all this having looked at the
specs of BCM8603.

> * Avoids (rather than fix) several SCSI core false dependencies on HCIL. 
>   Results in code duplication and/or avoidance of needed code.

No, not true.  It _integrates_ with SCSI Core.  The sad truth
is that SCSI Core knows only HCIL.

Jeff, please be more specific.

> * So far, it's an Adaptec-only solution.  Since it pointedly avoids the 
> existing SAS transport code, this results in two SAS solutions in Linux: 
> one for Adaptec, one for {everyone else}.

Hmm, again: _architecture_.  And you have to stop these
accusations: "pointedly avoids the existing SAS transport code".

I repeat again that I had this code _long_ before Christoph
ever dreamt up SAS.  And he got my code via James B sometime
before OLS this year.  I think he got it July 12, 2005.

The question is: why didn't _he_ use the solution already
available?

You have to understand the differences between MPT and open
transport architecture.

At some point I thought Christoph seemed to have understood it.
Now I'm not sure any more.

Now since the open transport solution completely encompasses
and _absolves_ MPT, it is not hard for an MPT driver to
generate a bunch of events and use that infrastructure.

> * Maintainer reminds me of my ATA mentor, Andre Hedrick:  knows his 
> shit, but has difficulties working with the community.  May need a 
> filter if we want long term maintenance to continue.

I take offence in your liking me to Andre -- I don't know
Andre personally, but is seems that you're expressing personal
opinion against him, against me and labeling me in some way.

I take offence in that, Jeff.

Why are you making this a _political_ and personal game?

All you're doing is trying to aliken me to someone and
brandish me as someone I'm not.

This is rude, offensive and done in desperation.

Shall we concentrate on the _technical_ part of
the argument?

I repeat again: _technical_ part of the argument.

> Easy path: make Adaptec's solution a block driver, which allows it to 
> sidestep all the "doesn't play well with others" issues.  Still an 

What _exactly_ does it mean "don't play well with others"?

Do you mean:
 - the solution is far superiour to anything available now
 - it presents the SAS Domain in sysfs as it looks in
   the physical world,
 - does domain discovery and expander configuration,
 - allows for complete control of the domain to user space,
 - it pokes at SCSI Core's 20 year old relics.
 - it's a thorn in the flesh to other people striving for
   similar functionality.

Or do you mean:
 - it does not change a single line of code in the kernel,
 - does not break anything existing,
 - etc, etc.

> Adaptec-only solution, but at least its in a separate playpen.

I'm sure James Bottomley will move from SCSI Core to the block
layer as he did for IDR. hehehe :-)

And no, it is not Adaptec's only solution.  Your BCM8603 SAS
LLDD when you write it could use it without any problems.

> Hard path: Update the SCSI core and libata to work with SATA+SAS 
> hardware such as Adaptec's.

Cannot do for libata -- ever.  Why?  You know best: because
libata uses direct access to the hardware!  There is no
layered architecture.

What you need to do is to write a SATL layer, just as you can
see in SAT-r6, page 2, Figure 3.  I'm on top of this already.

But in order to do this you need a unified architecture
for accessing ATA devices.

Now libata, uses ata_port to do this, which is _hardware_
access.

The SAS Transport layer uses Execute SCSI RPC (defined
in SAM, provided by aic94xx) to do this.

So in effect, what SATL would end up to be is a
data transformation function.   But I digress...

> The hard path takes time, and won't be solved simply by shoving it in.

No, you can do it now.  It will not affect anyone or anything.
(Other than hurting a couple of people's pride.)

The code doesn't alter Linux SCSI or anyone else's behaviour.
It only _provides_ SAS support to the kernel.

Including it in as is would does not hurt anyone as you can
see here:
http://linux.adaptec.com/sas/git/

Concentrate on the _technical_ merit, let's be more specific.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> The driver and the infrastructure needs to go in.
> 
> Give it exposure to the people, let people play with it.

Merging into the upstream kernel is not necessary for exposure.

Historically, saying "no" to a single vendor pushing really hard -- as 
you are doing -- has resulted in a superior solution.


> If we start "fixing" SCSI Core now (this in itself is JB red
> herring), how long before it is "fixed" and we can "rest"?
> And how long then before the driver and infrastructure
> makes it in?

Just follow the recipe Christoph outlined.  It's not difficult, just 
requires some work.


> At the end of the day the driver is not in, and business
> suffers.  And its not like the driver is using 
> static struct file_operations megasas_mgmt_fops, ;-)
> IOCTLs or other char dev for management...
> 
> The driver does _not_ alter anything in the kernel, it only
> integrates with it.
> 
> There needs to be a "passing gate":
> Linus, let the driver and transport layer in, as is and then
> patches "fixing SCSI Core" would start coming, naturally.
>>From people, from me, from everybody.

So far, this is an Adaptec-only solution.

It does an end run around 90% of the SCSI core.  You might as well make 
it a block driver, if you're going to do that.

	Jeff

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

[Jeff Garzik]

Luben Tuikov wrote:
> I request inclusion of the SAS Transport Layer
> and the AIC-94xx SAS LLDD into the Linux kernel.

Overall, I see the following major issues.  My recommendation is that 
this driver live in -mm, or outside the kernel tree, for a while to let 
things shake out.


Background
----------
* There is no question that Adaptec's aic94xx and SAS code is correct 
WRT the SCSI specifications.  The maintainer eats, sleeps, and breathes 
SAS specs.  :)

* aic94xx hardware supports both SAS and SATA connections.  Since SAS 
and SATA are intentionally similar electrically, other vendors are 
coming out with SATA+SAS hardware too.

* Acronym:  "HCIL"  Stands for Host/Channel/ID/LUN.  Pre-SAS legacy 
addressing method.


Issues
------
* Avoids existing SAS code, rather than working with it.

* Avoids existing SATA code, rather than working with it.

* Avoids (rather than fix) several SCSI core false dependencies on HCIL. 
  Results in code duplication and/or avoidance of needed code.

* So far, it's an Adaptec-only solution.  Since it pointedly avoids the 
existing SAS transport code, this results in two SAS solutions in Linux: 
one for Adaptec, one for {everyone else}.

* Maintainer reminds me of my ATA mentor, Andre Hedrick:  knows his 
shit, but has difficulties working with the community.  May need a 
filter if we want long term maintenance to continue.


Resolution
----------
AFAICS, there are two paths:

Easy path: make Adaptec's solution a block driver, which allows it to 
sidestep all the "doesn't play well with others" issues.  Still an 
Adaptec-only solution, but at least its in a separate playpen.

Hard path: Update the SCSI core and libata to work with SATA+SAS 
hardware such as Adaptec's.

The hard path takes time, and won't be solved simply by shoving it in.

	Jeff

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

[Luben Tuikov]

On 09/27/05 16:34, Jeff Garzik wrote:
> Luben,
> 
> The fact that your responses are constantly filled with non-technical 
> paranoia does not help the inclusion of aic94xx at all.
> 
> Maybe you need to write your driver as a block driver, and completely 
> skip the SCSI core, if it bothers you so much?  That would get everybody 
> else out of the loop, and free you to write the driver as you see fit.

Hi Jeff, how are you doing?

Yes, that has been suggested before.  But do you remember what
happened when I posted a patch to IDR?  James moved from SCSI Core
to IDR. hehehe ;-)

In the mids of the FUD, I completely removed IDR from being used
in aic94xx, long before I posted the driver.

> As it stands now, you're making an end run around the SCSI core, rather 
> than fixing it up.  SCSI needs to be modified for SAS, not just 
> complained about.

Well, back in 2001-2 I was asking for 64 bit LUN support and
for native SCSI target support (since iSCSI "exports" targets), and
it uses 64 bit LUNs (as any other transport).  Both sniffed at
and rejected by your friends.

See this thread from me, all the way back in 2002:
http://marc.theaimsgroup.com/?l=linux-scsi&m=103013448713434&w=2

You still have people from IBM who claim that 64 bit LUN
support is completely unnecessary as recently as 2 weeks ago.
(link to email on marc.10east.com available upon request)

As it has come to now, 2005, we cannot afford any more "putting off".

The driver and the infrastructure needs to go in.

Give it exposure to the people, let people play with it.

If we start "fixing" SCSI Core now (this in itself is JB red
herring), how long before it is "fixed" and we can "rest"?
And how long then before the driver and infrastructure
makes it in?

"How long is the long hair?"

You are calling for fixing SCSI Core.  JB is calling for
integrating MPT with open transport.  I'm sure people
have other (crazy) requests.

At the end of the day the driver is not in, and business
suffers.  And its not like the driver is using 
static struct file_operations megasas_mgmt_fops, ;-)
IOCTLs or other char dev for management...

The driver does _not_ alter anything in the kernel, it only
integrates with it.

There needs to be a "passing gate":
Linus, let the driver and transport layer in, as is and then
patches "fixing SCSI Core" would start coming, naturally.
>From people, from me, from everybody.

	Luben

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

[Jeff Garzik]

Luben Tuikov wrote:
> Instead of you _waiting_ and thus do nothing, you can
> move out of the way, or listen and accept _technical_ advice.
> 
> This is unfortunate.  History shows us that being
> inflexible to new ideas (or technologies) becomes
> one's undoing.
> 
> I wonder if SCSI Core could be Linux's undoing?  Could this
> and reiser4, and OBDs (yet another new SCSI technology in the
> making), show us how inflexible Linux has become?
> 
> Now its SAS and reiser4.  When OBDs come out full force it
> will be the block layer, then who knows whatelse...
> 
> Is Linux going to be just as obstinate?
> 
> Why has Linux become like this?


Luben,

The fact that your responses are constantly filled with non-technical 
paranoia does not help the inclusion of aic94xx at all.

Maybe you need to write your driver as a block driver, and completely 
skip the SCSI core, if it bothers you so much?  That would get everybody 
else out of the loop, and free you to write the driver as you see fit.

As it stands now, you're making an end run around the SCSI core, rather 
than fixing it up.  SCSI needs to be modified for SAS, not just 
complained about.

	Jeff

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

[Luben Tuikov]

On 09/27/05 11:53, James Bottomley wrote:
>>Christoph, why diseminate FUD, when we can concentrate on the
>>_technical_ merits of SCSI and SAS instead?
> 
> 
> That's what *we* are concentrating on.  Technically, I have no problem

Nah.  You're concentrating on blocking new drivers and _innovation_
from getting into SCSI Core.

Just look, for all these years you've been "maintaining" SCSI Core
it still uses HCIL, LUNS are u32, and you think that REQUEST SENSE
clears ACA, and scsi core has no representation of targets to save
its life.

It just hurts us all.

> with the aic94xx driver being based on a domain device.  However, you
> cannot have two separate transport classes for SAS.  So these two need
> to be unified before this driver becomes includable.

Apparently you do _not_ understand what the SCSI architecture
model is, again I refer you to the _picture_ here:
http://www.t10.org/scsi-3.gif

Now,

1) MPT _gives_ you LUs -- all transport _and_ SCSI specific work
has already been done for you.

2) With MPT you export attributes by poking, in a firmware
_dependent_ way, into the firmware of the controller.

That is, _all_ the "stuff" below SAM, as you can see in the picture
link, happens in the firmware!  What the firmware _gives_ you in a
_uniform_ way is SAM/SPC objects only (via the LLDD) so you can
register the LUs with SCSI Core, etc.

None of this is true for the SAS Transport Layer and
the AIC-94xx driver and BCM8603.   That is, for those solutions
the transport (SAS) architecture is exposed right down to
the phy/link layer.

So you _need_ transport management.  And since SAS sticks
to SAM so nicely and is so very well layered, it implements right
into what you have in the SAS Transport Layer.

> It looks to me to be a fairly simple exercise to unify these two classes
> giving LSI a functional interface and you a domain device based one and
> removing all the duplication of mid-layer functionality as part of doing
> this.

Ok, I'm aware that you're well aware that very few people actually
understand indepth MPT and other architectures.

You're posting FUD here, and hope that, since no one understands things
indepth, you can post anything you want, and sound credible.

I repeat again:

Those are two *radically* _different_ and _distinct_ technologies.

What MPT does is _everything_ *below* SCSI Core in terms of 
SAS Transport Layer and AIC-94xx LLDD.

That is all the work you see done in the SAS Transport Layer
and in AIC-94xx IS DONE ALREADY IN THE FIRMWARE!

What our solution and apparently BCM9603 does is expose _all_
that.

What you need to do is:
  - Let the code in _now_, as is.
  - Let _people play_ with it as hardware comes more available.
    I said "people" not necessarily you and/or Christoph.
  - Let it evolve in the hands of the people.
  - Hear feedback from the people.
  - Accept patches.
  - Let it evolve.

IOW, do not bastardise it now when you have _no_ SAS or SCSI
expertise, or hardware (well, maybe you have some on the way
from your friends at XYZ).

>>The SAS Transport Class (your an JB's incarnation) is _not_
>>a management infrastructure, it was _never_ _intended_ to be.
> 
> 

JB's statement A:
> Actually, it was intended to be such.  The sysfs components of the
> transport class are the unified management interface to the transport.

If it was _ever_ intended to be such, then it would sit
_below_ SCSI Core _and_ SCSI Core would NEVER be aware of it.
(just as it is on the picture, see?)

Even the _name_ suggests it: SCSI transport _attributes_,
and it is a template to export _attributes_.

You *CANNOT* write a template for _all_ transports, since this
is what SCSI Core is supposed to be!  This is what
SAM/SPC _is_!  This is what SCSI Core should be striving to.

The transport management layer sits _BELOW_ SCSI Core,
and _manages_ the particular transport, just like the SAS Transport
Layer.  SCSI Core does only SAM/SPC tasks, and is _unaware_ of
the transport.  (How hard is this to understand?)

See the _pictures_ on t10.org and the "techno-gibberish" posted
there?

JB's statment B:
> No, the point of a transport class is to export the underlying
> attributes of the actual devices that are present.  This is supposed to

Exactly! And this statement B here, contradicts your statement A) above.

Note: it is a transport _class_, _not_ a management _layer_, which is
what you have with the SAS Transport Layer.

> be independent of the driver used to connect to them (and that's what
> your sas class breaks).

Mine is _not_ a class.  It is a transport layer to _manage_ and drive
SAS LLDDs.

LSI's driver is NOT, to repeat it is NOT a SAS LLDD!  It is an *MPT* LLDD.

Your "transport attribute class" provides hooks for exporting
_attributes_ from MPT-based LLDDs.

It does _NOT_ provide for a management infrastructure:
1) because there is none needed -- the LLDD is MPT and you're providing
   attribute exporting only,
2) All this is _firmware_ implemented.

I repeat again: you cannot have a single _template_ for all-protocol
_management_ as you're implying.

For the record: I think MPT is a wonderful technology in its right
and the SAS LSI's solution should've been accepted right when it
was posted, since it didn't have any SAS in it.  The only thing
it had was a few different PCI IDs, AFAIR looking at the patch.

> I've told you before, if you find something that's broken send a patch
> in to fix it.  I've already told you why the code in sas_discover can't
> work for other drivers (although I still don't have an explanation from

Nah, lets not go with this BS:  "I've already told you...", it just
doesn't work.  Be specific.  See above how much effort I put in
repeating myself over and over and over again.  And I put
the effort to actually type everything out.

> you of why scsi_scan_target can't work for sas_discover).

Why?  Because it uses HCIL?  Because LUN are represented as u32?
Because you think that a LUN is a "u64".  Because you think that
REQUEST SENSE clears ACA?

>>What needs fixing is, SCSI Core to
>>	- not use HCIL,
>>	- use 64 bit LUNs,
>>	- know about SCSI devices with Target ports,
>>	- proper representation of SCSI Domains
>>          (FC, USB, IEEE 1394, Infiniband, SAS, iSCSI)
> 
> 
> As I've already said several times you're welcome to send in a patch to
> change this as well ... as long as you either don't break every other
> driver, or fix them all with the patch.

This is complete FUD and you know it and it is just the political game
you've been playing all this time.

Proof:

1) Any patches submitted to lsml, you change and then you resubmit
yourself, unless of course they come in from a few "chosen" people.
I.e. people who do not challenge your antics.

This _policy_ disourages people from actually doing any new and
innovative work with SCSI Core.

2) You are well aware that NONE of SCSI Core is relevant as it stands
today for a new, SAM/SPC abiding architecture like SAS.  You know very
well that other than LUN scanning and some SAM/SPC tasks, one needs
very little to support SAS.

3) Your own effort on this (converting LUN to "u64") failed:
http://marc.10east.com/?l=linux-scsi&m=112664309529813&w=2

YET, you try to keep this semantically fat, overloaded with lots of
little quirks for old hardware, SCSI Core.

You have to let things in, so that they can evolve naturally.
You cannot give heart attack to 50 or so LLDDs.

> You were given a step by step
> procedure at least for the I replacement piece.

How many times do I have to tell you that this was Christoph's
reply to an email of mine _asking_ me if this were the way to do it?

And then I told him that it is not quite the way to do it?
See this link:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112507133514575&w=2

> The only power of a maintainer is to say "no".  So, although I cannot
> make you fix any of the problems in your submission, I can say no until
> an acceptable submission comes along for this driver.

You see, you and I do not see eye to eye, since we do not have the same
base: T10.org.

I read books, specs, drafts, firmware, code, presentations, lectures,
etc.  It isn't easy, but necessary to do my job better and better every
day.  It is necessary so that I'm knowlegable and can provide immediate
response and help when asked to.

So I'm not sure about your point of view.  SCSI 20 years ago?

I'm not sure what kind of convicing it would take?

Maybe we can do a presentation in front of an audience of _storage_
folks?  We can both explain out points of view.

> At this point, I
> believe all the technical issues of what needs to happen are well
> understood;

Nah.  You're just saying this to manipulate the readers of this
thread.  Or maybe those "needs" are well understoood _in your head_
only?  I told you before: be _specific_.

What needs improvement is NOT the SAS Transport Layer and/or
aic94xx LLDDs.

What needs improvement, in order to _better_ _accomodate_
_new_ technologies is SCSI Core.  If not even a new SCSI Core
developed in parallel (so the old one can be config-not-compile
if one has no legacy controllers and devices and vice-versa).

SCSI Core is 20 years _behind_.  And thus _Linux_ SCSI
is 20 years behind.  Apparently no one cares.

When you get your new shiny mainboard with an AIC-94xx
chip on it (check with SuperMicro), which can handle SAS and SATA,
you do not need to compile this fat, old and semantically broken
SCSI Core, but a smaller, faster one.

> I also believe that this is an important enough piece of

Since when do you think it is important?  This is the first
time you're saying this and I think someone was talking to
you. XYZ?

> hardware that an acceptable driver will come along even if you want to
> play dog in the manger, so all I can do is wait.

So what you're saying is "my way or the highway"?

"all I can do is wait"?
James, why not just simply move out of the way?

Instead of you _waiting_ and thus do nothing, you can
move out of the way, or listen and accept _technical_ advice.

This is unfortunate.  History shows us that being
inflexible to new ideas (or technologies) becomes
one's undoing.

I wonder if SCSI Core could be Linux's undoing?  Could this
and reiser4, and OBDs (yet another new SCSI technology in the
making), show us how inflexible Linux has become?

Now its SAS and reiser4.  When OBDs come out full force it
will be the block layer, then who knows whatelse...

Is Linux going to be just as obstinate?

Why has Linux become like this?

	Luben

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

[James Bottomley]

On Tue, 2005-09-27 at 11:01 -0400, Luben Tuikov wrote:
> On 09/27/05 09:19, Christoph Hellwig wrote:
> > On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
> > 
> >>P.S. This is a second resend of an identical message
> >>I posted to lkml and lsml yesterday.
> > 
> > 
> > And it's not gotten anymore includable.  Please fix the major structural
> Christoph, why diseminate FUD, when we can concentrate on the
> _technical_ merits of SCSI and SAS instead?

That's what *we* are concentrating on.  Technically, I have no problem
with the aic94xx driver being based on a domain device.  However, you
cannot have two separate transport classes for SAS.  So these two need
to be unified before this driver becomes includable.

It looks to me to be a fairly simple exercise to unify these two classes
giving LSI a functional interface and you a domain device based one and
removing all the duplication of mid-layer functionality as part of doing
this.

> Why talk non-constructive things, when we can have a SCSI Storage
> discussion?
> 
> > issues pointed out when you first sent it out.  That's in the following
> > order:
> > 
> >  - not trying to integrate with the sas transport class in Linus'
> 
> Well here we go _again_:
> 
> The SAS Transport Class (your an JB's incarnation) is _not_
> a management infrastructure, it was _never_ _intended_ to be.

Actually, it was intended to be such.  The sysfs components of the
transport class are the unified management interface to the transport.

> The whole point of it is to _export_ *attributes* of MPT-technology
> like drivers.  All those drivers that it caters to _do_ _not_ need a
> _management_ layer (Discovery, Expander configuration, etc.).
> They "export" SCSI LUs directly to SCSI Core through their LLDDs.

No, the point of a transport class is to export the underlying
attributes of the actual devices that are present.  This is supposed to
be independent of the driver used to connect to them (and that's what
your sas class breaks).

> >  - duplicating the lun scanning code instead of using the scsi core one
> 
> The LUN scanning code is, uum, how to say this nicely... wrong?
> It did its job for Parallel SCSI and for broken arrays who do not
> respond to REPORT LUNS, but have a bunch of disks behind, but it is
> wrong _by design_ and it is _not_ _relevant_ in SAS.  To properly see
> how LUN scanning is done, look at sas_discover.c.

I've told you before, if you find something that's broken send a patch
in to fix it.  I've already told you why the code in sas_discover can't
work for other drivers (although I still don't have an explanation from
you of why scsi_scan_target can't work for sas_discover).

> What needs fixing is, SCSI Core to
> 	- not use HCIL,
> 	- use 64 bit LUNs,
> 	- know about SCSI devices with Target ports,
> 	- proper representation of SCSI Domains
>           (FC, USB, IEEE 1394, Infiniband, SAS, iSCSI)

As I've already said several times you're welcome to send in a patch to
change this as well ... as long as you either don't break every other
driver, or fix them all with the patch.  You were given a step by step
procedure at least for the I replacement piece.

> Christoph how long are you and James Bottomley going to hold
> SCSI Core _hostage_ to new technologies?

The only power of a maintainer is to say "no".  So, although I cannot
make you fix any of the problems in your submission, I can say no until
an acceptable submission comes along for this driver.  At this point, I
believe all the technical issues of what needs to happen are well
understood; I also believe that this is an important enough piece of
hardware that an acceptable driver will come along even if you want to
play dog in the manger, so all I can do is wait.

James

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

[Luben Tuikov]

On 09/27/05 09:19, Christoph Hellwig wrote:
> On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
> 
>>P.S. This is a second resend of an identical message
>>I posted to lkml and lsml yesterday.
> 
> 
> And it's not gotten anymore includable.  Please fix the major structural

Major?

Christoph, why diseminate FUD, when we can concentrate on the
_technical_ merits of SCSI and SAS instead?

Why talk non-constructive things, when we can have a SCSI Storage
discussion?

> issues pointed out when you first sent it out.  That's in the following
> order:
> 
>  - not trying to integrate with the sas transport class in Linus'

Well here we go _again_:

The SAS Transport Class (your an JB's incarnation) is _not_
a management infrastructure, it was _never_ _intended_ to be.

The whole point of it is to _export_ *attributes* of MPT-technology
like drivers.  All those drivers that it caters to _do_ _not_ need a
_management_ layer (Discovery, Expander configuration, etc.).
They "export" SCSI LUs directly to SCSI Core through their LLDDs.

If you cared to read any of the "techno-babble" (as you call it)
documents and specs you'd clearly see how and _why_ it fits
with a SCSI Stack.  As baby food, see this _picture_:
http://www.t10.org/scsi-3.gif
For an adult meal, maybe some reading of "techno-babble"
would help?

>    tree at all, not even using the transport class infrastructure
>    at all, creating it's own sysfs trees in rather wierd ways

"weird ways" ?  Did you care to see what a SAS domain looks like?
There is plenty of references, slides, course notes, etc on the
Internet.

Christoph, I work with this technology every day.  OTOH, you
blocked LSI's drivers from going in until they sent you hardware
just a month ago.

What you see in sysfs is _exactly_ what you'd see in the _physical_
world, _including_ the "locking" -- i.e. the "kobject_get".  It "locks"
object which are needed for the command to travel to, in _actuallity_.

If you say that it is "weird" then you are also saying that
a SAS Domain in the *physical* world is weird.

It is the _natural_ representation of the SAS domain.

What seems "weird" to you, is what it _actually_ is.

This is what this new technology is.  You can learn it
or you can call it "weird" and "techno-babble", and invent
your own understanding of SAS and shove it down the throat
of thousands of Linux users and vendors.

>  - not beeing structures as a library (ala libata which is a very good
>    model for it)

It _cannot_ be presented as a library, because _again_ it is a
*management layer*, an infrastructure.

What it manages is, _again_ to repeat myself, SAS objects:
ports, connections, devices, discovery, expander management, etc.

See the original Announcement 0 here, it explains this in detail:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629423714248&w=2

>  - duplicating the lun scanning code instead of using the scsi core one

The LUN scanning code is, uum, how to say this nicely... wrong?
It did its job for Parallel SCSI and for broken arrays who do not
respond to REPORT LUNS, but have a bunch of disks behind, but it is
wrong _by design_ and it is _not_ _relevant_ in SAS.  To properly see
how LUN scanning is done, look at sas_discover.c.

SCSI Core does not know about everyday SCSI objects like a "SCSI
Device with a Target port". It does things backwarads _and_ foremost
of all, it uses _HCIL_.

What needs fixing is, SCSI Core to
	- not use HCIL,
	- use 64 bit LUNs,
	- know about SCSI devices with Target ports,
	- proper representation of SCSI Domains
          (FC, USB, IEEE 1394, Infiniband, SAS, iSCSI)

Christoph, SCSI Core is 20 years behind.

I appreciate your aggresiveness and JB's political games,
but what it comes down to, Linux SCSI, vendors, users, and
its _other_ developers suffer.

Anyway, when all you have is an AIC-94xx or BCM8603 chip on your
mainboard (check with SuperMicro) you *do not need* the semantically
fat, broken and wrong SCSI Core (catering to old, outdated, broken
SPI machines).

You need a _minimal_ SCSI Core, SAM/SPC-like, when you have a new
technology like SAS and _none_ of the semantically fat and broken
SCSI Core is _relevant_ in a SAS world.

Christoph how long are you and James Bottomley going to hold
SCSI Core _hostage_ to new technologies?

How long are you going to _block_ SCSI storage innovation
from the Linux kernel?

Or is this the new way of embezzling hardware from vendors?
Is this what is done in the other Linux kernel subsystems?

I don't get it.  If you or James Bottomley think that
	- LUNS can be represented as "u64", and
	- sending REQUEST SENSE clears ACA,
	- "SCSI Device with Target port" is "techno-babble",
how can you drive new SCSI technology?

Someone please pinch me, because I'm dreaming this horrible
nightmare.

	Luben

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

[Christoph Hellwig]

On Tue, Sep 27, 2005 at 09:07:24AM -0400, Luben Tuikov wrote:
> P.S. This is a second resend of an identical message
> I posted to lkml and lsml yesterday.

And it's not gotten anymore includable.  Please fix the major structural
issues pointed out when you first sent it out.  That's in the following
order:

 - not trying to integrate with the sas transport class in Linus'
   tree at all, not even using the transport class infrastructure
   at all, creating it's own sysfs trees in rather wierd ways
 - not beeing structures as a library (ala libata which is a very good
   model for it)
 - duplicating the lun scanning code instead of using the scsi core one

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

[Luben Tuikov]

Hi Linus,

I request inclusion of the SAS Transport Layer
and the AIC-94xx SAS LLDD into the Linux kernel.

Please find your latest git tree with SAS
Transport Layer and AIC-94xx, patches and
a whole tar.bz2 tree here:

http://linux.adaptec.com/sas/

There you will also find the original announcements
posted to this list.

The code is updated twice daily or more often as
needed.

Thank you,
	Luben
P.S. This is a second resend of an identical message
I posted to lkml and lsml yesterday.

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

[Luben Tuikov]

Hi everyone,

I request inclusion of the SAS Transport Layer
and the AIC-94xx SAS LLDD into the Linux kernel.

Please find the latest Linus' git tree with SAS
Transport Layer and AIC-94xx, patches and
a whole tar.bz2 tree here:

http://linux.adaptec.com/sas/

There you will also find the original announcements
posted to this list.

The code is updated twice daily or more often as
needed.

Thank you,
	Luben