On 07/14/2014 05:10 PM, Hannes Reinecke wrote: > On 07/14/2014 04:57 PM, James Bottomley wrote: >> On Mon, 2014-07-14 at 16:39 +0200, Hannes Reinecke wrote: >>> On 07/14/2014 04:17 PM, James Bottomley wrote: > [ .. ] >>>> 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. We have a strong 'upstream first' policy in our releases for new drivers and for new patches, so in theory upstream could use the force, I still prefer a softer way that is discussing it with Avago(LSI) and getting their ack. >>>> >>> 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. >> I'm not saying we need to go into why this happened. Just that I'd like >> community agreement amongst the distros before trying to force the >> issue. I accept that the distros respond to their TAMs as well as the >> community, but if there's going to be TAM push back, I'd at least like >> to hear about it so I can have a word with the relevant people. >> >>> 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. >> Then we need a maintainer of that driver ... remember this is a fat >> firmware driver with a proprietary interface. It's hard to maintain and >> update without docs ... unless you happen to have an NDA copy? >> > Hmm. _if_ the driver is similar to the original one (which was the > idea) it should be reasonably trivial to port the latest changes > from the original driver to the merged one. I think you expect more or less that after that new driver is created it will be maintained again by Avago(LSI), so let us hear what they think first. >From my point of view the not optimal thing already has happened, both driver exist and both are included in our major releases. The change is probably better for the long-term maintainability of the driver, but from the distro perspective any switch to a new driver adds some new work, because we don't want to remove any particular old driver which has been included to a major release. That said, I agree that we (Red Hat) will manage the change, since it is the better approach for the long-term maintenance of the driver in the upstream". Cheers, Tomas > >>> 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:-) >> The best is to get LSI to agree, yes ... hence the need for unanimity. >> > Agreed. Let's see what LSI has to say here. > > Cheers, > > Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
