[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101015030336.GB9640@elte.hu>
Date: Fri, 15 Oct 2010 05:03:36 +0200
From: Ingo Molnar <mingo@...e.hu>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Casey Dahlin <cdahlin@...hat.com>, x86@...nel.org,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch] x86: allow ZONE_DMA to be configurable
* H. Peter Anvin <hpa@...or.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists