Messages in this thread | | | Date | Thu, 25 Sep 2008 17:40:28 -0400 | From | "Parag Warudkar" <> | Subject | Re: [patch 00/04] RFC: Staging tree (drivers/staging) |
| |
On Thu, Sep 25, 2008 at 4:53 PM, Greg KH <gregkh@suse.de> wrote: > > Heh, ok, so the basic premise of getting code that is not currently in > mergable shape into the tree earlier to get wider usage and testing is > something that you agree with?
I don't think I got my point across - let me try again.
My disagreement was with getting crap code in mainline, re-classifying it as something other than experimental when it is not, expecting users to use it, printing warning when it is used, tainting the kernel for even more harassment and then having developers not support it as a bonus - all cumulative. The naming part was also something that I did not like but that like I said was just my preference and does not matter because I disagree there is no need to TAINT in first place.
I can imagine that getting crap code in mainline is helpful for some class of users and developers - no problem we can have it in on that basis - I give up my objection there.
But my objections to the other parts remain - i.e. we should definitely avoid the useless re-classification and TAINT, we should change little or no other kernel code in the process of integrating this crap, give enough deterrent for people to really think before loading the crap code, and do not make it an official statement that you will get no support on LKML if you load this driver. Because certainly not all developers agree and we by definition of this staging effort have an interest in fixing the code.
The below approach I referred few times earlier will allow us to do exactly that - it would be good if you can tell me if this is workable.
1) Give a staging directory for all such low quality crap 2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and if that is selected allow users to individually select the crappy drivers they want to actually use - default all entries to N 3) Name all modules under staging with a _stg suffix or something unique 4) By default do NOT load anything with a _stg suffix - deal with this in insmod code, not the kernel 5) Require that -f be specified to load _stg modules - which will auto-taint the kernel and developers can decide on their judgment / situation whether or not to pursue it 6) OOPS reports with force loaded taint and _stg in module list will allow developers to decide whether or not to go after it
The above approach avoids re-classification/TAINTING, touches no kernel code and does not load the crap code automatically and still allows you to do what you intended.
Hopefully this doesn't sound like another "let us arm wrestle on what to name it" - because it is clearly more than that!
Parag
| |