Messages in this thread | | | Date | Wed, 24 Sep 2008 22:59:03 -0400 | From | "Parag Warudkar" <> | Subject | Re: [patch 00/04] RFC: Staging tree (drivers/staging) |
| |
On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote: > No, this is much different from EXPERIMENTAL. That flag is pretty much > useless right now. This is for a temporary landing place for drivers > that are not good enough to be merged, yet are useful enough for some > people to use.
How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and CONFIG_EXPERIMENTAL are no different - neither to users nor to developers. Here is why - Both try to do the same thing - let people use the drivers on their own risk (as if the stable ones are developer's risk - but let's keep it aside for the moment) and give developers a chance to keep the code in sync with mainline and improve it per user problem reports or generally make it better.
You might try to differentiate between them on the basis of relative brokenness or crappiness if you will - but it is essentially the same - code that is not ideal for merge in mainline, code that needs user testing to trash out problems, and code that need to be in sync with mainline and code that users want to use in order to be able to use their hardware. I fail to see how this is different at all.
> > Examples of this is the USB driver I posted, some network drivers that > are in -staging that only work on x86 boxes, and drivers that have > userspace interfaces that are "wrong" and need to be changed (reading > files from /etc is one example.) >
I don't see a reason to further classify and label the experimental code - it is experimental. That classification suffices.
> Also, api changes do not have to propagate into the drivers/staging/ > directory. I'll work to keep up with them, keeping everything working > properly, just like I have been with the external -staging tree. This > is just pushing it into the tree to give it much wider exposure and draw > from more developers makeing it easier to give them the proper credit > for this clean-up work.
Sure. Merge them under EXPERIMENTAL - may be with a big fat colored KConfig warning about what is broken. Tainting and labeling it staging does nothing of any value add. Sure you can have a staging directory in the tree and dump all the unmergeable code there if that gives a sense of isolation but I do not see a point in letting users build the staging code, loading it without their intervention and then printing a warning and tainting the kernel.
So what if there is a oops report tomorrow and we know it is Tainted : EXPERIMENTAL - OOPS reports generally are very indicative of where the problem is coming from and the knowledge that certain broken driver is loaded is just fine to be outside the kernel - no need for the TAINT intimidation which drives away users from reporting it and developers from addressing it.
> I think the boat has left on making EXPERIMENTAL mean anything anymore, > but if you or anyone else wants to clean up the tree, and free it up, > then I would reconsider using it here instead. But you can't start > making it something that means more than it does today, as I can easily > see that breaking systems that currently rely on those drivers.
There's the clue - this _will_ happen with staging - I can almost see it. So why not do it under one existing monster of an umbrella - or do you have plans to make sure you are not going to add a new staging driver unless the existing ones graduate to stable? Even if you do - doable under EXPERIMENTAL.
Parag
| |