Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Thu, Sep 25, 2008 at 4:53 PM, Greg KH <gregkh@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/