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

[Sean Paul <seanpaul@chromium.org>]

On Wed, Sep 5, 2018 at 9:56 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Wed, Sep 05, 2018 at 03:35:53PM +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.
>
> The only one that comes to mind is comedi.  I think those guys know that
> everyone is fine with them moving the code.
>
> Do you have another example?
>

The android stuff has been in a constant state of almost graduating
for a while now.

> >
> > - Code changes in staging are mostly only scratching surfaces, minor
> >   code style cleanups, etc, what checkpatch suggests.
>
> That's probably true for the wireless drivers because converting them
> to use mac80211 is complicated.  The other drivers seem to be doing
> better.
>

We have the same problem in drm. There have been a few subsystem
refactors that have missed updating drivers in staging. It's also
trickier to coordinate refactors across drm/staging trees. As such, we
have been trying to dissuade people from using staging for drm.

> >
> > - 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.
>
> Which ones are you interested in?  I'd always prefer to hand off staging
> drivers to an existing subsystem but it's not always clear who that
> should be.

In the case of vboxvideo, we won't accept it in drm since it's not an
atomic driver. staging's bar for entry was lower, so the driver was
stuck in there. Perhaps we would have been better to take it in drm
behind a config, but that's not ideal either.

Sean

>
> regards,
> dan carpenter
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss