Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 4950 bytes --]

On Tue, 2014-05-27 at 20:10 -0400, Martin K. Petersen wrote:
> >>>>> "Jiri" == Jiri Kosina <jkosina@suse.cz> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]