lkml.org 
[lkml]   [2005]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
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


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

\
 
 \ /
  Last update: 2005-09-28 23:02    [W:0.170 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site