[Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better?

Daniel Vetter daniel.vetter at ffwll.ch
Wed Sep 5 16:35:19 UTC 2018


On Wed, Sep 5, 2018 at 6:21 PM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Wed, 2018-09-05 at 15:35 +0200, Takashi Iwai wrote:
>> The staging driver is a wonderful process to promote the downstream
>> code to the upstream, but I have doubt whether it's working really as
>> expected for now.
>>
>> - Often the drivers live forever in staging although they should have
>>   been moved to the upper, properly maintained, subsystems.
>>
>> - Code changes in staging are mostly only scratching surfaces, minor
>>   code style cleanups, etc, what checkpatch suggests.
>>
>> - There are little communications with the corresponding subsystem;
>>   already a few times I was surprised by casually finding a staging
>>   driver code by grepping for preparing API changes.
>>
>> - Then some drivers are pushed back after long time stay in staging
>>   (lustre is the recent remarkable case);
>>   it's understandable, but is definitely no happy end in both sides,
>>   after all.
>>
>> So, I'd like to hear how we can improve the staging driver situation,
>> a better communication with staging driver people and the subsystem /
>> core devs.
>
> I think subsystems should be able to opt out of staging entirely.  For
> SCSI, we want to look at the substantive command interaction issues and
> (for our manifold sins) are used to reading code that makes your eyes
> bleed, so polishing staging drivers with whitespace changes for months
> doesn't serve us at all.

>From drm's pov I second this. I have no problem with looking at very
un-kernel coding style from new drivers, if that allows us to
course-correct them on the fundamental issues right away. Polishing
can happen onces the fundamentals are sound. Before that it's just
busy work imo. Which I think is ok, it makes for great starter tasks,
but we already try to collect more relevant cleanup tasks for drm
under Documentation/gpu/todo.rst. Heck I'm totally fine merging a
driver that violates half of the checkpatch.pl bikesheds directly into
drm, as long as it's up-to-date with latest drm helpers and concepts.
Gives us good fodder for newbies and interns :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Ksummit-discuss mailing list