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.
* 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
* 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.
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"?
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.
The code doesn't alter Linux SCSI or anyone else's behaviour.
It only _provides_ SAS support to the kernel.