Re: mpt2sas and mpt3sas merge (again)

[Hannes Reinecke <hare@suse.de>]

On 07/14/2014 04:17 PM, James Bottomley wrote:
> On Mon, 2014-07-14 at 11:22 +0200, Hannes Reinecke wrote:
>> On 07/14/2014 10:35 AM, Christoph Hellwig wrote:
>>> Back when the mpt3sas driver was first posted I suggested that it should
>>> be merged into mpt2sas, but my proposal didn't get much traction.
>>>
>>> Illumos has now produced a shared driver and shown that the difference
>>> are basically limited to a different S/G list format [1], and a quick
>>> experiment on the Linux drivers confirms this mostly - the additional
>>> differences are various smaller workarounds for specific hardware
>>> revisions.
>>>
>>> I think we'd all be served much better with a merged driver.
>>>
>>> [1] http://thread.gmane.org/gmane.os.illumos.devel/17341
>>
>> Please. Pretty please.
>
> I support the concept, since I think everyone told LSI at the time that
> splitting the drivers would become a maintenance nightmare.
>
>> I've started a merge myself, but then never found time to finalize it.
>>
>> Carrying three basically identical drivers just creates a
>> maintenance overhead for everyone involved.
>>
>> The original idea of splitting the driver and just maintaining the
>> latest has never really worked out; all fixes to the latest driver
>> turned out to be applicable to the others, too.
>> So it just increased the workload for the maintainer for no real
>> gain. I would _strongly_ vote for it.
>
> This isn't really a democracy; it's about who maintains the drivers and
> right now it's LSI (or whatever their new name is).
>
> One of the big reasons we don't have a lot of leverage with them is that
> they always seem to slide updates around upstream via the distros
> (often,  it has to be admitted the DKM route), so if Red Hat, SUSE,
> Oracle and Canonical can agree not to accept LSI updates until the
> driver is done this way, we'd have a lot more leverage.
>
Hmm. We (as SUSE) have been striving to have a 'upstream first' 
policy. IE for any new release the drivers have to be upstream 
before we consider including it in our release.
This is most certainly true for the upcoming SLE-12 release, and 
also has been enforced for the current SLES11 SP3 release.

This is official company policy, and has been communicated to all 
our partners.
We do accept driver updates (ie patches which are not upstream ATM), 
but only on the understanding that the vendor will have to push the 
patches upstream eventually.
If they don't the patches will be kicked out of the next release.
(Which is what happened to the mptsas v4 release; it never made it 
upstream and so got dropped from SLE-12).

However, this cuts both ways; we cannot go and tell our partners to 
change the driver if upstream hasn't done it first.

So the push has to come from us (as the linux kernel developers); 
after all, we should make the decision what goes in and what 
doesn't. If a driver is in a bad state (and it's actually us which 
defines the 'bad state') we should be discussing on how we would 
like to improve things.
If the maintainer proves unwilling to implement our suggestions we 
can always go ahead and implement a separate driver.

Look what happened to hpsa; this was the pretty much the showcase on 
how it should be done:
Tomo went ahead and re-implemented the cciss driver, and eventually 
HP adopted it as their main driver.
I agree that was pretty much the optimal case, though:-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html