This option is aimed to add the possibility to control a menu's visibility
without adding dependency to the expression to all the submenu.
Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This fixes the use-after-free and associated crash in kconfig introduced
in commit 246cf9c2.
Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This silences the warning printed upon prompt redefinition for the rootmenu.
We will encounter this redefinition when a "mainmenu" statement is specified and
override the default prompt.
Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NMichal Marek <mmarek@suse.cz>

Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Reviewed-by: NRandy Dunlap <rdunlap@xenotime.net>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NMichal Marek <mmarek@suse.cz>

Signed-off-by: NArnaud Lacombe <lacombar@gmail.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NMichal Marek <mmarek@suse.cz>

When we add a new config symbol save the file/line
so we later can refer to their location.

The information is saved as a property to a config symbol
because we may have multiple definitions of the same symbol.

This has the side-effect that a symbol always has
at least one property.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

The "select" statement in Kconfig files allows the enabling of options
even if they have unmet direct dependencies (i.e. "depends on" expands
to "no"). Currently, the "depends on" clauses are used in calculating
the visibility but they do not affect the reverse dependencies in any
way.

The patch introduces additional tracking of the "depends on" statements
and prints a warning on selecting an option if its direct dependencies
are not met.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Those configs are not new:

  $ cat .config
  ...
  CONFIG_NAMESPACES=y
  ...
  CONFIG_BLOCK=y
  ...

But are tagged as NEW:

  $ yes "" | make config > myconf
  $ cat myconf | grep '(NEW)'
  Namespaces support (NAMESPACES) [Y/?] (NEW) y
  ...
  Enable the block layer (BLOCK) [Y/?] (NEW) y
  ...

You can also notice this bug when using gconfig/xconfig.

It's because the SYMBOL_DEF_USER bit of an invisible symbol is cleared
when the config file is read:

int conf_read(const char *name)
{
	...
	for_all_symbols(i, sym) {
		if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
			/* Reset values of generates values, so they'll appear
			 * as new, if they should become visible, but that
			 * doesn't quite work if the Kconfig and the saved
			 * configuration disagree.
			 */
			if (sym->visible == no && !conf_unsaved)
				sym->flags &= ~SYMBOL_DEF_USER;
	...
}

But a menu item which represents an invisible symbol is still
visible, if it's sub-menu is visible, so its SYMBOL_DEF_USER
bit should be set to indicate it's not NEW.
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Without this patch, one has to refer to the Kconfig file to find
out the range of an integer/hex symbol.

  │ Symbol: NR_CPUS [=4]
  │ Type  : integer
  │ Range : [2 8]
  │ Prompt: Maximum number of CPUs
  │   Defined at arch/x86/Kconfig:761
  │   Depends on: SMP [=y] && !MAXSMP [=n]
  │   Location:
  │     -> Processor type and features
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Randy suggested to print out the symbol type in gconfig.

Note this change does more than Randy's suggestion, that it also
affects menuconfig and "make config".

  │ Symbol: BLOCK [=y]
  │ Type  : boolean
  │ Prompt: Enable the block layer
  │   Defined at block/Kconfig:4
  │   Depends on: EMBEDDED [=n]
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Usage:
  Press <Z> to show all config symbols which have prompts.

Quote Tim Bird:

| I've been bitten by this numerous times.  I most often
| use ftrace on ARM, but when I go back to x86, I almost
| always go through a sequence of searching for the
| function graph tracer in the menus, then realizing it's
| completely missing until I disable CC_OPTIMIZE_FOR_SIZE.
|
| Is there any way to have the menu item appear, but be
| unsettable unless the SIZE option is disabled?  I'm
| not a Kconfig guru...

I myself found this useful too. For example, I need to test
ftrace/tracing and want to be sure all the tracing features are
enabled, so I  enter the "Tracers" menu, and press <Z> to
see if there is any config hidden.

I also noticed gconfig and xconfig have a button "Show all options",
but that's a bit too much, and I think normally what we are not
interested in those configs which have no prompt thus can't be
changed by users.

Exmaple:

      --- Tracers
      -*-   Kernel Function Tracer
      - -     Kernel Function Graph Tracer
      [*]   Interrupts-off Latency Tracer
      - -   Preemption-off Latency Tracer
      [*]   Sysprof Tracer

Here you can see 2 tracers are not selectable, and then can find
out how to make them selectable.
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

- fix a typo in documentation
- fix a typo in a printk on error
- fix comments in dialog_inputbox()
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This patch was inspired by the kernel projects page, where an ncurses
replacement for menuconfig was mentioned (by Sam Ravnborg).

Building on menuconfig, this patch implements a more modern look
interface using ncurses and ncurses' satellite libraries (menu, panel,
form). The implementation does not depend on lxdialog, which is
currently distributed with the kernel.
Signed-off-by: NNir Tzachar <nir.tzachar@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Warnings found via gcc -Wmissing-prototypes.
Signed-off-by: NTrevor Keith <tsrk@tsrk.net>
Acked-by: NWANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Futhermore, gconfig interface lack the "search a symbol" function, do later.
Signed-off-by: NCheng Renquan <crquan@gmail.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
[sam: fix SEGV in gconfig]
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The three functions are moved from mconf.c, then they can be shared in
all menuconfig & gconfig & xconfig & config.

  +void menu_get_ext_help(struct menu *menu, struct gstr *help)
  +static void get_prompt_str(struct gstr *r, struct property *prop)
  +void get_symbol_str(struct gstr *r, struct symbol *sym)
Signed-off-by: NCheng Renquan <crquan@gmail.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

We have had warnings for a long time about select of unknow symbol
but the warnings does not really makes sense since we may
select a symbol that is relevant and defined in one
arch but not in another arch.
And as long as we do not use a common set of Kconfig files
for all archs lets just ignore this case.

Previously we have used this to find bad uses of
select but we need a more relaible method to do so.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>

Change kconfig behavior so that mixing bool and tristate config
settings in a choice is possible and has the desired effect of offering
just the tristate options individually if the choice gets set to M, and
a normal boolean selection if the choice gets set to Y.

Also fix scripts/kconfig/conf's handling of children of choice values -
there may be more than one immediate child, and all of them need to be
processed.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Cc: "Roman Zippel" <zippel@linux-m68k.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Add the possibility to import a value from the environment into kconfig
via the option syntax. Beside flexibility this has the advantage
providing proper dependencies.
Documented the options syntax.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Rename E_CHOICE to E_LIST to explicitly add support for expression
lists. Add a helper macro expr_list_for_each_sym to more easily iterate
over the list.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This patch removes the indirect I18N support for config file.
Signed-off-by: NEgry Gabor <gaboregry1@t-online.hu>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>

This reverts commit a5bf3d89.

David Brownell notes that this causes a regression visible in the
drivers/usb/gadget Kconfig file:

  "That Kconfig hasn't changed (other than adding new drivers), and it's
   worked that way for several years now ...  so the issue seems to be
   changes in menuconfig/kconfig/etc semantics.

   The issue is that when USB_GADGET=m, it's no longer possible to
   configure peripheral controller drivers as modules ...  the
   controller drivers can now only be configured for static linkage.

   It should be making a choice of one of the controller drivers which
   could work on the target system, and allow that driver to be linked
   either as a module (ok iff USB_GADGET=m) or statically."

Reverting this commit resolves the problem, and also fixes a second
problem that David noticed: various dependent options couldn't be enabled.
Tested-and-reported-by: NDavid Brownell <david-b@pacbell.net>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Jan Beulich <jbeulich@novell.com>,
Cc: Andrew Morton <akpm@linux-foundation.org>,
Cc: Sam Ravnborg <sam@ravnborg.org>,
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Change kconfig behavior so that mixing bool and tristate config settings in
a choice is possible and has the desired effect of offering just the
tristate options individually if the choice gets set to M, and a normal
boolean selection if the choice gets set to Y.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Roman Zippel wrote:
> A simple example would be
> help texts, right now they are per symbol, but they should really be per
> menu, so archs can provide different help texts for something.

This patch does this and at the same time introduce a few API
funtions used to access the help text.

The relevant api functions are introduced in the various frontends.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>

Correct a minor spelling mistake in a Kconfig warning message.
Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Kconfig does its own indentation of menu prompts, so warn about and ignore
leading whitespace.  Remove also a few unnecessary newlines after other
warning prints.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This makes it possible to change two options which were hardcoded sofar.
1. Any symbol can now take the role of CONFIG_MODULES
2. The more useful option is to change the list of default file names,
   which kconfig uses to load the base configuration if .config isn't
   available.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This adds the general framework to the parser to define options for config
symbols with a syntax like:

config FOO
	option bar[="arg"]
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Add a few error tokens to the parser to catch common errors and print more
descriptive error messages.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This allows variable arguments in the range option for int and hex config
symbols.
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've
had to add a return value to menu_add_prompt for one usage.

I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes
in the source (I've not the same Bison version so regenerating it wouldn't
have been not a good idea), and compared it with what Roman itself did some
time ago, and it's the same.

So I guess this can be finally merged.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This patch adds i18n support for make *config, allowing users to have the
config process in their own language.

No printk was harmed in the process, don't worry, so all the bug reports,
kernel messages, etc, remain in english, just the user tools to configure
the kernel are internationalized.

Users not interested in translations can just unset the related LANG,
LC_ALL, etc env variables and have the config process in plain english,
something like:

LANG= make menuconfig

is enough for having the whole config process in english. Or just don't
install any translation file.

Translations for brazilian portuguese are being done by a team of
volunteers at:

http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes

To start the translation process:

  make update-po-config

  This will generate the pot template named scripts/kconfig/linux.pot,
  copy it to, say, ~/es.po, to start the translation for spanish.

To test your translation, as root issue this command:

  msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po

  Replace "es" with your language code.

  Then execute, for instance:

  make menuconfig

The current patch doesn't use any optimization to reduce the size of the
generated .mo file, it is possible to use the config option as a key, but
this doesn't prevent the current patch from being used or the translations
done under the current scheme to be in any way lost if we chose to do any
kind of keying.

Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese)
translation effort, Thiago Maciera for helping me with the gconf.cc (QT
frontent) i18n coding and to all the volunteers that are already working on
the first translation, to pt_BR.

I left the question on whether to ship the translations with the stock kernel
sources to be discussed here, please share your suggestions.
Signed-off-by: NArnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org
Signed-off-by: NAndrew Morton <akpm@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!