All of lore.kernel.org
 help / color / mirror / Atom feed
From: gwr <gwr@free.fr>
To: linux-config@vger.kernel.org
Subject: Re: Kconfig entry defined multiple times
Date: Wed, 22 Aug 2012 10:59:37 +0200	[thread overview]
Message-ID: <50349F79.4060907@free.fr> (raw)
In-Reply-To: <50349C28.1060107@free.fr>


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

      reply	other threads:[~2012-08-22  8:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22  8:05 Kconfig entry defined multiple times gwr
2012-08-22  8:42 ` gwr
2012-08-22  8:45 ` gwr
2012-08-22  8:59   ` gwr [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50349F79.4060907@free.fr \
    --to=gwr@free.fr \
    --cc=linux-config@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.