[ bringing back on list ] On Fri, 2005-07-29 at 16:28 -0600, Moore, Eric Dean wrote: > On Friday, July 29, 2005 2:14 PM, Luben Tuikov wrote: > > Eventually when LSI writes a smaller FW of their SAS HA, and > > make use of Discovery in the kernel... because it is > > economically _unfeasible_ to notify so many customers to upgrade > > their FW, when a bug is discovered in the field, then they > > can plug right in and make use of the always current and up > > to spec Discovery code in the kernel. ;-) > > > > That won't fly. We will never do that. Ok guys, let's please stop the vendor in-fighting. It is serving neither of you. Let's please agree that both Adaptec's part as well as LSI's part *need* to be supported in kernel.org. > > > Well, to be fair, this includes drive spin-up time and looking for > > raidset headers. I don't know how long just discovery takes. Eric? > > Drives attached to single expander takes a matter seconds to do discovery. > I've not tested with layered expanders yet. But I would never expect 30 > seconds. Let's worry about benchmarks later. Once we get the software into the kernel, LSI and Adaptec can go head-to-head about whose part is faster. That way, everybody wins. Better drivers, better parts. So, how do we move forward? Who is writing the SAS Transport Class? Christoph? Luben? Can I help? Can we use Luben's patch (not yet posted to list) as a starting point? Eric, can you make LSI's driver fit into this paradigm? If not, what needs to be changed? -tduffy
Attachment:
signature.asc
Description: This is a digitally signed message part
