[Ksummit-discuss] [TOPIC] Encouraging more reviewers

[Martin K. Petersen]

>>>>> "Ben" == Ben Hutchings <ben at decadent.org.uk> writes:

Ben> I seem to recall one OEM formally requiring in-tree drivers for all
Ben> components aside from graphics.  But they usually wanted
Ben> out-of-tree driver packages *as well*, since 'enterprise' customers
Ben> do like to run old kernel versions.

Cc: stable :)

Ben> Driver development for a new generation of hardware may begin long
Ben> before it is publicly announced, and may contain many false starts
Ben> or temporary hacks to work around pre-release hardware or
Ben> simulations.  Somehow, that messy development branch needs to be
Ben> turned into some semblance of coherent refactoring when sending
Ben> upstream.  Either that or you fork and rename the driver for the
Ben> new generation, and send it upstream with no history at all.

I agree that the history situation is different for completely new
drivers. However, the problem at hand is code we've had in the kernel
for a long time. It is still widely used but has bitrotted or is in a
shape that would never get accepted into the kernel by today's
standards.

Vendors use arguments like "we developed and tested this outbox driver
version x.y.z thoroughly in a 2.6.15 environment on i386. Didn't see any
problems, therefore it works with every kernel a customer might
run". Such a statement may carry some weight in a stable kernel
interface world but it is completely meaningless in our case.

-- 
Martin K. Petersen	Oracle Linux Engineering