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
