No.
The point is that using the *same* flag to control whether I can select
a mostly-working USB widget and a mostly-working Ethernet driver is Just Wrong.
Those of us who live in the US may have seen the insurance commercial where
Joe Sixpack is asking "Honey, what does this switch do?" "I don't know" flip,
flip, flip with no obvious impact. Meanwhile, 3 houses down, somebody's car
is being beat up by a garage door opener going open/close/open/close...
I enable EXPERIMENTAL to enable my USB widget. When the next release comes out,
I then go and do something like a 'make [foo]config'. What indication do I
get that now-selectable device drivers are 'depends on EXPERIMENTAL' and *not*
safe for selection? (Yes, in menuconfig, you can ask it to show the 'depends
on' list, *if* you suspect that it might be an issue. But why would I suspect
that?)
In no case should we be creating a situation where users are thinking "Damn,
every driver may or may not be bodgy, I have to *check* if it's experimental
before I enable it, just because there was one that I *asked* for".
Particularly fun if you're migrating to new hardware and you don't *know* yet
which drivers you need, and you're getting prompted for possibly-dodgy ALSA
modules because you asked for a USB module....
(And yes, trying to wade through all the ALSA/Intel HDA/AC97/Sigmatel *was*
painful enough when I moved from a Dell Latitude C840 to a D820 - fortunately
enough, I didn't have to deal with EXPERIMENTAL ALSA drivers adding to the
mix.. )
EXPERIMENTAL in a mainline kernel as a *single* switch for a *lot* of totally
unreleated code is even more broken than EMBEDDED (which at least had a common
rationale). And over in the -mm kernel where it *should* be, it's superfluous
at best, because a -mm kernel might as well just add -DCONFIG_EXPERIMENTAL=y to
CFLAGS and save you the effort. ;)
