From mboxrd@z Thu Jan 1 00:00:00 1970 From: gwr Subject: Re: Kconfig entry defined multiple times Date: Wed, 22 Aug 2012 10:59:37 +0200 Message-ID: <50349F79.4060907@free.fr> References: <503492D8.9030109@free.fr> <50349C28.1060107@free.fr> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50349C28.1060107@free.fr> Sender: linux-config-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-config@vger.kernel.org On 08/22/2012 10:45 AM, gwr wrote: > > On 08/22/2012 10:05 AM, gwr wrote: >> Hello, >> >> I am working on kernel 2.6.32.38, and I see : >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> arch/x86/Kconfig, 202 : >> ============= >> >> config USE_GENERIC_SMP_HELPERS >> def_bool y >> depends on SMP >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> arch/Kconfig, 112 : >> =========== >> >> config USE_GENERIC_SMP_HELPERS >> bool >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Although we have this in Kconfig documentation, >> ================================================ >> A config option can be defined multiple times with the same name, but >> every >> definition can have only a single input prompt and the type must not >> conflict. >> ================================================ >> >> here, >> - the first definition is a child of "Linux Kernel Configuration >> for x86" MainMenu ( arch/x86/Kconfig, 1 ) >> - the second definition is a child of "General setup" Menu ( >> init/Kconfig, 24 ) >> >> So the hierarchy is different ; Can someone give explanations on this ? >> >> Thx >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-config" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > I forgot the second half on my message : > > - I am trying to build a linux kernel configurator that do not need to > reparse > all the kernel Kconfig input at each entry modification > > - the problem : > > -- if I keep the 2 entries as separates objects, I cant choose > between the 2 at > expression evaluation time,because the second definition has no > dependancy. > > -- the second definition has no dependancy => it suggest that the > 2 entries have to be joined into a single entry. But at which > place in the hierarchy ? > > ( note : a "make gconfig" ends up with 2 different > USE_GENERIC_SMP_HELPERS entries in the tree ) > > > > Now consider the X86_EXTENDED_PLATFORM entry : > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > arch/x86/Kconfig,312 : > ============= > > if X86_32 > config X86_EXTENDED_PLATFORM > bool "Support for extended (non-PC) x86 platforms" > default y > ---help--- > ( ...help text 1... ) > endif > > if X86_64 > config X86_EXTENDED_PLATFORM > bool "Support for extended (non-PC) x86 platforms" > default y > ---help--- > ( ...help text 2... ) > endif > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > the dependancies are mutually exclusive. > > > > > So in fact, the real question I ask is : could not be Kconfig grammar > simplified, by adding some restricting rules ? > > Thx > Simplification could be NOT ALLOWING multiple entries with the same name, I counted only 14 "entries with duplicate name" in my 2.6.32.38 kernel, among many thousands entries. Example : X86_EXTENDED_PLATFORM could easily redeclared simply by allowing dependancies to help texts. Thx