Re: [patch] x86: allow ZONE_DMA to be configurable

[Ingo Molnar]

* H. Peter Anvin <hpa@xxxxxxxxx> wrote:

> I don't like the CONFIG_EXPERT prefix, just because it makes it hard 
> to move things into and out of this rubric, and that's bad... 

Hm, i'm not sure i agree.

> (consider: "oh, that would mean this *huge* patch) ...

If config options are present in many places in the source that's an 
independent problem already.

Typically kconfig variables are used in a few places and any rename 
patch makes it clear in all those places what happened: either a config 
variable became obscure (moved into CONFIG_EXPERT's scope), *or* a 
config variable became much less obscure (moved out of that scope) - 
both important pieces of information, which i dont mind to see happen in 
every place that gets affected.

Put differently: if we have a CONFIG_EXPERT_ kconfig variable in so many 
places in the kernel that it creates a huge patch then we have some 
other kind of problem: it either should not be an expert option (it's 
too common or too important), or it should not be an option at all (it's 
a perpetual build failure risk).

Also, historically we have not been moving kconfig variables in and out 
of CONFIG_EMBEDDED all that often for this to be an issue in the future.

> [...] not to mention that what is CONFIG_EXPERT on one platform may 
> not be for another! [...]

Dunno, that i'd consider more of a bug. If an architecture absolutely 
needs to configure in or out a kernel feature then it should not be 
under CONFIG_EXPERT on other architectures either: it only sets us up 
for cross-arch build failures if say the CONFIG_EXPERT dependency is 
present on x86.

Or, if an architecture still wants it that way, it better be explicitly 
aware that it's configuring in a little-tested kconfig switch of the 
kerenl.

I.e. something being an 'expert option' is synonymous with obscurity and 
potential weirdness on at least one arch - which i dont see as 
inherently wrong to be visible (via the name) on other architectures 
either.

Thanks,

	Ingo
--
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/