On Mon, 26 Nov 2007 23:34:11 EST, Dave Jones said: > On Mon, Nov 26, 2007 at 10:44:44PM -0500, [email protected] wrote: > > > I suspect that given the "once it escapes, it's cast in stone" view we take > > towards user-visible API/etc, there isn't much *real* room for an > > 'EXPERIMENTAL' flag anymore. Most of the usage should probably be confined to > > individual drivers, where all we should need is a 'default n' and suitable > > warning verbiage in the Kconfig file warning about the driver eating your > > filesystems and small animals for breakfast. > > Potential corruptors are usually flagged with (DANGEROUS) in the text, Right, and given that, an additional EXPERIMENTAL flag seems superfluous. > (One may argue that they shouldn't have escaped -mm) > > > We certainly shouldn't have > > one big flag for *all* in-progress drivers - I don't need to accidentally > > enable a busticated ethernet driver because I want a USB widget. > > So no ethernet driver at all is better than a broken but mostly working one? > Again if it isn't mostly working, it shouldn't have escaped -mm 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. ;)
Attachment:
pgpxENl9rmnWO.pgp
Description: PGP signature
- References:
- [2.6 patch] remove CONFIG_EXPERIMENTAL
- From: Adrian Bunk <[email protected]>
- Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
- From: Pavel Machek <[email protected]>
- Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
- From: [email protected]
- Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
- From: Dave Jones <[email protected]>
- [2.6 patch] remove CONFIG_EXPERIMENTAL
- Prev by Date: Re: [PATCH 38/54] efivars: remove new_var and del_var files from sysfs
- Next by Date: Re: 2.6.24-rc3-mm1
- Previous by thread: Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
- Next by thread: Re: [2.6 patch] remove CONFIG_EXPERIMENTAL
- Index(es):
 |