On Tue, 2014-05-27 at 20:10 -0400, Martin K. Petersen wrote: > >>>>> "Jiri" == Jiri Kosina writes: > > Jiri> Are you implying that Linux is still not in a position to force HW > Jiri> vendor companies to rather invest 30 man-minutes in order to have > Jiri> a proper changelog and driver merged in Linus' tree compared to > Jiri> receiving bad public press when they are being rejected > Jiri> (especially for such negligible reason as changelog text)? > > There are a few companies in the enterprise space that get it. But in > general it can be quite the challenge to get these vendors to see the > value of being good Linux citizens. And these companies are much less > susceptible to phoronix rants than entities producing consumer widgets. For consumer widgets, it appears that most vendors don't update the software, so they won't care that any out-of-tree drivers may break on the next kernel version. In fact, they're likely to be starting with their SoC vendor's kernel tree which was forked a few years ago and has a ton of dirty performance hacks in the core. The 'enterprise' world seems to be in a comparatively much better state. > These companies have internal development processes that are often quite > unfriendly to the way we work. More often than not, upstream drivers are > trailing internal driver trees by many, many months. Patches are only > sent upstream when there is a bit of slack in the engineering schedule. > > In many cases upstream Linux is not seen as an important target because > the driver vendor will provide OEMs that ship their hardware with a > "value added" outbox driver tarball or CD. The server vendors are > partially to blame for keeping this dreadful anachronism alive. One > would think that "It Just Works with RHEL/SLES/OL" would be better story > than retrofitting tarball drivers and jeopardizing future kernel > updates. In my experience working for an 'enterprise' hardware vendor, there was definitely pressure from OEMs to get the hardware supported in mainline or in their favoured distribution (and distribution maintainers require them to be upstream first). I seem to recall one OEM formally requiring in-tree drivers for all components aside from graphics. But they usually wanted out-of-tree driver packages *as well*, since 'enterprise' customers do like to run old kernel versions. > According to the server vendors, however, customers expect to > install an updated Linux driver just like they do on Windows. Otherwise > the perception is that Linux is lagging behind or poorly supported. > *sigh* Chip/board vendors and OEMs often like to differentiate themselves in a competitive market by implementing unique features and adding special applications and driver interfaces to support these. Linux subsystem maintainers may push back against such interfaces - often because they are not all that unique, or not likely to remain so. David Miller is particularly strict about this; other maintainers may be less so. This does not block differentiation, but it means those features may be included only in the OOT driver. When an OEM is interested in differentiation, then of course it will encourage use of the OOT driver. > Vendor driver release cycles are often tied exclusively to new silicon > availability and internal firmware release schedules. Many vendors pay > little to no attention to Linux development cycles. Furthermore, driver > code is often shared between several operating systems so every patch > needs to undergo IP/legal review before it can be submitted upstream. > Internal commit messages often have partner references, bug numbers, > code names, etc. in them. So it's typically easier to just drop the > patch description than rewriting it and have the new text reviewed by > the legal team. [...] I never had to go through legal review, though I certainly sanitised some commit messages based on my own knowledge of what product information was and wasn't already public. Other reasons I had for needing to write new commit messages: - The internal commit message had just a bug number and one line of summary, because the internal bug tracker had the full explanation - I combined and/or split some internal commits, because we discovered a regression before sending them upstream Driver development for a new generation of hardware may begin long before it is publicly announced, and may contain many false starts or temporary hacks to work around pre-release hardware or simulations. Somehow, that messy development branch needs to be turned into some semblance of coherent refactoring when sending upstream. Either that or you fork and rename the driver for the new generation, and send it upstream with no history at all. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer