Re: [ANNOUNCE 0/2] Serial Attached SCSI (SAS) support for the Linux kernel

[Andrew Patterson <andrew.patterson@hp.com>]

On Mon, 2005-09-12 at 17:35 -0400, Luben Tuikov wrote:
> On 09/11/05 05:20, Christoph Hellwig wrote:
> > Thanks for finally posting your code.
> > 
> > At the core it's some really nice code dealing with host-based SAS
> > implementations.
> 
> Thank you Christoph.  Much appreciated.
> 
> > What's not nice is that it's not intgerating with the
> > SAS transport class I posted,
> 
> I wish there was something I could do.  HP and LSI
> were aware of my efforts since the beginning of the year.

I know I am going to regret getting pulled into this ;-(.

This effort started on April.  Eric Moore, Mike Miller and I started
work on a SAS transport class and then later pulled Luben it at the
suggestion of Douglas Gilbert (if I remember correctly).  We later
mutually agreed that Luben would take over the transport class work as
he seemed to have much more experience with this sort of thing.  The
original idea was to implement a SAS transport class that would allow
the LSI and Adaptec driver to get into kernel.org (or others at the
time) and to find a way to get SDI/CSMI API's into the kernel without
the use of IOCTL's.  Luben then went off on his own and came up with his
effectively Adaptec only solution.

> 
> As well, you had a copy of my code July 14 this year,
> long before starting your work on your SAS class for LSI and
> HP (so its acceptance is guaranteed), after OLS.

HP never suggested that Christoph do a SAS transport layer. We were
happy to provide some equipment when we found out that he was working on
it.  Please don't speak for HP. I am sure that LSI would prefer you
don't speak for them either.

> 
> We did meet at OLS and we did have the SAS BOF.  I'm not sure
> why you didn't want to work together?

If my memory serves correctly, there were 10-12 people at that BOF,
representing the SCSI kernel maintainers and all of the vendors
currently providing SAS hardware.  Virtually everyone disagreed with
your implementation (which you indeed emailed shortly before the
conference) that would only work with one vendor's card. The suggestion
was made that you convert your code to various library layers so that it
would work with all vendors.  A suggestion which it seems that you
continue to reject.

> 
> > it's duplicating things like LUN disocvery
> 
> This is a much more involved subject than meets the eye.
> 
> > from the SCSI core code, and adding it's own sysfs representation that's
> > very different from the way the SCSI core and transport classes do it.
> 
> Yes, it is time to evolve.
> 
> I've pointed out many times the shortcomings of expanding the
> JB's "transport _attribute_ class" into a "transport layer" in
> recent threads.
> 
> I'm sorry but over everything else, we need a common base,
> (what you call "techno-gibberish") in order to see eye to eye.
> 
> > Are you willing to work with us to intgerate it with the infrastructure
> > we have?
> 
> I'm sure you've already taken a closer look at the SAS code 
> I posted.   Study it, read the spec, read the code again.
> 
> Let me know if I can help with anything.
> 
> Overall, MPT is very different in design than a disclosed
> transport.  Talk to HP, LSI and Dell and see what they think.

From HP's point of view (or mine at least).  We would prefer something
that works with every vendors card.  Not Adaptec's (or is it Luben's)
vision of the perfect card.

Andrew
-- 
Andrew Patterson                
Hewlett-Packard

Attachment: signature.asc
Description: This is a digitally signed message part