Messages in this thread | | | Date | Tue, 27 Sep 2005 22:02:16 -0400 | From | Jeff Garzik <> | Subject | Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel |
| |
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
- 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/
| |