linux.git/scripts/kconfig/symbol.c, branch v2.6.36

kconfig: Temporarily disable dependency warnings

2010-10-09T21:19:07+00:00

After fixing a use-after-free bug in kconfig, a 'make defconfig' or
'make allmodconfig' fills the screen with warnings that were not
detected before. Given that we are close to the release now, disable the
warnings temporarily and deal with them after 2.6.36.

Signed-off-by: Michal Marek

kconfig: fix segfault when detecting recursive dependency

2010-08-14T22:32:13+00:00

Following sample Kconfig generated a segfault:

config FOO
        bool
        select PERF_EVENTS if HAVE_HW_BREAKPOINT

config PERF_EVENTS
        bool

config HAVE_HW_BREAKPOINT
        bool
        depends on PERF_EVENTS

Fix by reverting back to a valid property if there was no
property on the stack of symbols.

The above pattern were seen in sh Kconfig.
A fix for the Kconfig file has been sent to the sh folks.

Signed-off-by: Sam Ravnborg 
Signed-off-by: Michal Marek

kconfig: add savedefconfig

2010-08-03T11:49:32+00:00

savedefconfig will save a minimal config to a file
named "defconfig".

The config symbols are saved in the same order as
they appear in the menu structure so it should
be possible to map them to the relevant menus
if desired.

The implementation was tested against several minimal
configs for arm which was created using brute-force.

There was one regression related to default numbers
which had their valid range further limited by another symbol.

Sample:

config FOO
	int "foo"
	default 4

config BAR
	int "bar"
	range 0 FOO

If FOO is set to 3 then BAR cannot take a value higher than 3.
But the current implementation will set BAR equal to 4.

This is seldomly used and the final configuration is OK,
and the fix was non-trivial.
So it was documented in the code and left as is.

Signed-off-by: Sam Ravnborg 
Acked-by: Uwe Kleine-König 
Signed-off-by: Michal Marek

kconfig: refactor code in symbol.c

2010-08-03T11:49:32+00:00

Move logic to determine default for a choice to
a separate function.
No functional changes.

Signed-off-by: Sam Ravnborg 
Signed-off-by: Michal Marek

kconfig: print more info when we see a recursive dependency

2010-08-03T11:49:31+00:00

Consider following kconfig file:

config TEST1
	bool "test 1"
	depends on TEST2

config TEST2
	bool "test 2"
	depends on TEST1

Previously kconfig would report:

foo:6:error: found recursive dependency: TEST2 -> TEST1 -> TEST2

With the following patch kconfig reports:
foo:5:error: recursive dependency detected!
foo:5:  symbol TEST2 depends on TEST1
foo:1:  symbol TEST1 depends on TEST2

Note that we now report where the offending symbols are defined.
This can be a great help for complex situations involving
several files.

Patch is originally from Roman Zippel with a few adjustments by Sam.

Signed-off-by: Sam Ravnborg 
Cc: Roman Zippel 
Signed-off-by: Michal Marek

kconfig: save location of config symbols

2010-08-03T11:49:31+00:00

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: Sam Ravnborg 
Cc: Roman Zippel 
Signed-off-by: Michal Marek

kconfig: Don't write invisible choice values

2010-07-08T12:38:14+00:00

This makes it so "make oldconfig" really prompts for any choice where
options that previously weren't visible just became so. Previously one
would have to remember to go over all choice values and check whether
some that previously couldn't be selected now can be.

Signed-off-by: Jan Beulich 
Signed-off-by: Michal Marek

kbuild: Warn on selecting symbols with unmet direct dependencies

2010-07-02T12:53:09+00:00

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: Catalin Marinas 
Cc: Sam Ravnborg 
Cc: Arnd Bergmann 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Signed-off-by: Michal Marek

kconfig: recalc symbol value before showing search results

2010-03-23T11:29:07+00:00

A symbol's value won't be recalc-ed until we save config file or
enter the menu where the symbol sits.

So If I enable OPTIMIZE_FOR_SIZE, and search FUNCTION_GRAPH_TRACER:

  Symbol: FUNCTION_GRAPH_TRACER [=y]
  Prompt: Kernel Function Graph Tracer
    Defined at kernel/trace/Kconfig:140
    Depends on: ... [=y] && (!X86_32 [=y] || !CC_OPTIMIZE_FOR_SIZE [=y])
    ...

From the dependency it should result in FUNCTION_GRAPH_TRACER=n,
but it still shows FUNCTION_GRAPH_TRACER=y.

Signed-off-by: Li Zefan 
Signed-off-by: Michal Marek

Improve kconfig symbol hashing

2010-02-02T13:33:55+00:00

While looking for something else I noticed that the symbol
hash function used by kconfig is quite poor. It doesn't
use any of the standard hash techniques but simply
adds up the string and then uses power of two masking,
which is both known to perform poorly.

The current x86 kconfig has over 7000 symbols.

When I instrumented it showed that the minimum hash chain
length was 16 and a significant number of them was over
30.

It didn't help that the hash table size was only 256 buckets.

This patch increases the hash table size to a larger prime
and switches to a FNV32 hash. I played around with a couple of hash
functions, but that one seemed to perform best with reasonable
hash table sizes.

Increasing the hash table size even further didn't
seem like a good idea, because there are a couple of global
walks which walk the complete hash table.

I also moved the unnamed bucket to 0. It's still the longest
of all the buckets (44 entries), but hopefully it's not
often hit except for the global walk which doesn't care.

The result is a much nicer distribution:
(first column bucket length, second number of buckets with that length)

1: 3505
2: 1236
3: 294
4: 52
5: 3
47: 1		<--- this is the unnamed symbols bucket

There are still some 5+ buckets, but increasing the hash table
even more would be likely not worth it.

This also cleans up the code slightly by removing hard coded
magic numbers.

I didn't notice a big performance difference either way
on my Nehalem system, but I presume it'll help somewhat
on slower systems.

Signed-off-by: Andi Kleen 
Signed-off-by: Michal Marek