linux-kernel - Re: [patch] x86: allow ZONE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/