Messages in this thread | | | Date | Wed, 28 Sep 2005 17:00:07 -0400 | From | Jeff Garzik <> | Subject | Re: 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/
| |