Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 1月, 2018 2 次提交
    • P
      kconfig: make "Selected by:" and "Implied by:" readable · 1ccb2714
      由 Petr Vorel 提交于 
      Reverse dependency expressions can get rather unwieldy, especially if
a symbol is selected by more than a handful of other symbols. I.e. it's
possible to have near endless expressions like:
   A && B && !C || D || F && (G || H) || [...]

Chop these expressions into actually readable chunks:
   - A && B && !C
   - D
   - F && (G || H)
   - [...]

I.e. transform the top level OR tokens into newlines and prepend each
line with a minus. This makes the "Selected by:" and "Implied by:" blurb
much easier to read. This is done only if there is more than one top
level OR. "Depends on:" and "Range :" were deliberately left as they are.

Based on idea from Paul Bolle.
Suggested-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NPetr Vorel <petr.vorel@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1ccb2714
    • M
      kconfig: announce removal of oldnoconfig if used · 312ee687
      由 Masahiro Yamada 提交于 
      The 'oldnoconfig' is really confusing due to its counter-intuitive name.
It was renamed by commit fb16d891 ("kconfig: replace 'oldnoconfig'
with 'olddefconfig', and keep the old name as an alias").

The 'oldnoconfig' has been kept as an alias for enough period of time,
and finally I am planning to remove it.  I will give people a little
more time for migration.  Meanwhile, the following message will be
displayed if oldnoconfig is used.

    WARNING: "oldnoconfig" target will be removed after Linux 4.19
              Please use "olddefconfig" instead, which is an alias.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      312ee687
  3. 22 1月, 2018 3 次提交
  5. 21 1月, 2018 17 次提交
  7. 11 1月, 2018 2 次提交
    • U
      kconfig: Don't leak 'option' arguments during parsing · bc28fe1d
      由 Ulf Magnusson 提交于 
      The following strings would leak before this change:

	- option env="LEAKED"
	- option defconfig_list="LEAKED"

These come in the form of T_WORD tokens and are always allocated on the
heap in zconf.l. Free them.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,616 bytes in 14,355 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,568 bytes in 14,352 blocks
	   ...
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      bc28fe1d
    • U
      kconfig: Don't leak 'source' filenames during parsing · 24161a67
      由 Ulf Magnusson 提交于 
      The 'source_stmt' nonterminal takes a 'prompt', which consists of either
a T_WORD or a T_WORD_QUOTE, both of which are always allocated on the
heap in zconf.l and need to have their associated strings freed. Free
them.

The existing code already makes sure to always copy the string, but add
a warning to sym_expand_string_value() to make it clear that the string
must be copied, just in case.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 387,504 bytes in 15,545 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,616 bytes in 14,355 blocks
	   ...
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      24161a67
  9. 10 1月, 2018 1 次提交
    • U
      kconfig: Don't leak symbol names during parsing · 26e47a3c
      由 Ulf Magnusson 提交于 
      Prior to this fix, zconf.y did not free symbol names from zconf.l in
these contexts:

	- After T_CONFIG ('config LEAKED')
	- After T_MENUCONFIG ('menuconfig LEAKED')
	- After T_SELECT ('select LEAKED')
	- After T_IMPLY ('imply LEAKED')
	- After T_DEFAULT in a choice ('default LEAKED')

All of these come in the form of T_WORD tokens, which always have their
associated string allocated on the heap in zconf.l and need to be freed.

Fix by introducing a new nonterminal 'nonconst_symbol' which takes a
T_WORD, fetches the symbol, and then frees the T_WORD string. The
already existing 'symbol' nonterminal works the same way but also
accepts T_WORD_QUOTE, corresponding to a constant symbol. T_WORD_QUOTE
should not be accepted in any of the contexts above, so the 'symbol'
nonterminal can't be reused here.

Fetching the symbol in 'nonconst_symbol' also removes a bunch of
sym_lookup() calls from actions.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 711,571 bytes in 37,756 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 387,504 bytes in 15,545 blocks
           ...
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      26e47a3c
  11. 16 12月, 2017 4 次提交
    • M
      kconfig: generate lexer and parser during build instead of shipping · 29c83306
      由 Masahiro Yamada 提交于 
      zconf.lex.c is generated by flex, zconf.tab.c by bison.  Instead of
running flex and bison during the kernel building, we conventionally
version-control those artifacts with _shipped suffix.

It is tedious to manually regenerate them every time we change the
real sources, zconf.l and zconf.y.

Remove the _shipped files and switch over to build-time generation
of the intermediate C files.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      29c83306
    • M
      kbuild: prepare to remove C files pre-generated by flex and bison · 033dba2e
      由 Masahiro Yamada 提交于 
      In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix.  During the kernel building,
they are simply shipped (copied) removing the suffix.

This approach can reduce external tool dependency for the kernel build,
but it is tedious to manually regenerate such artifacts from developers'
point of view.  (We need to do "make REGENERATE_PARSERS=1" every time
we touch real source files such as *.l, *.y)

Some months ago, I sent out RFC patches to run flex, bison, and gperf
during the build.

In the review and test, Linus noticed gperf-3.1 had changed the lookup
function prototype.  Then, the use of gperf in kernel was entirely
removed by commit bb3290d9 ("Remove gperf usage from toolchain").

This time, I tested several versions of flex and bison, and I was not
hit by any compatibility issue except a flaw in flex-2.6.3; if you
generate lexer for dtc and genksyms with flex-2.6.3, you will see
"yywrap redefined" warning.  This was not intentional, but a bug,
fixed by flex-2.6.4.  Otherwise, both flex and bison look fairly
stable for a long time.

This commit prepares some build rules to remove the _shipped files.
Also, document minimal requirement for flex and bison.

Rationale for the minimal version:
The -Wmissing-prototypes option of GCC warns "no previous prototype"
for lexers generated by flex-2.5.34 or older, so I chose 2.5.35 as the
required version for flex.  Flex-2.5.35 was released in 2008.  Bison
looks more stable.  I did not see any problem with bison-2.0, released
in 2004.  I did not test bison-1.x, but bison-2.0 should be old enough.

Tested flex versions:
  2.5.35
  2.5.36
  2.5.37
  2.5.39
  2.6.0
  2.6.1
  2.6.2
  2.6.3   (*)
  2.6.4

 (*) flex-2.6.3 causes "yywrap redefined" warning

Tested bison versions:
  2.0
  2.1
  2.2
  2.3
  2.4
  2.4.1
  2.5.1
  2.6
  2.6.1
  2.6.2
  2.6.3
  2.6.4
  2.6.5
  2.7
  2.7.1
  3.0
  3.0.1
  3.0.2
  3.0.3
  3.0.4
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      033dba2e
    • M
      kbuild: add LEX and YACC variables · 73a4f6db
      由 Masahiro Yamada 提交于 
      Allow users to use their favorite lexer / parser generators.
This is useful for me to test various flex and bison versions.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      73a4f6db
    • M
      kconfig: display recursive dependency resolution hint just once · e3b03bf2
      由 Masahiro Yamada 提交于 
      Commit 1c199f28 ("kbuild: document recursive dependency limitation
/ resolution") probably intended to show a hint along with "recursive
dependency detected!" error, but it missed to add {...} guard, and the
hint is displayed in every loop of the dep_stack traverse, annoyingly.

This error was detected by GCC's -Wmisleading-indentation when switching
to build-time generation of lexer/parser.

scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’:
scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
   if (stack->sym == last_sym)
   ^~
scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
    fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n");
    ^~~~~~~

I could simply add {...} to surround the three fprintf(), but I rather
chose to move the hint after the loop to make the whole message readable.

Fixes: 1c199f28 ("kbuild: document recursive dependency limitation / resolution"
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      e3b03bf2
  13. 15 12月, 2017 3 次提交
    • U
      kconfig: Clean up modules handling and fix crash · f77850d3
      由 Ulf Magnusson 提交于 
      Kconfig currently doesn't handle 'm' appearing in a Kconfig file before
the modules symbol is defined (the symbol with 'option modules'). The
problem is the following code, which runs during parsing:

	/* change 'm' into 'm' && MODULES */
	if (e->left.sym == &symbol_mod)
		return expr_alloc_and(e, expr_alloc_symbol(modules_sym));

If the modules symbol has not yet been defined, modules_sym is NULL,
giving an invalid expression.

Here is a test file where both BEFORE_1 and BEFORE_2 trigger a segfault.
If the modules symbol is removed, all symbols trigger segfaults.

	config BEFORE_1
		def_tristate y if m

	if m
	config BEFORE_2
		def_tristate y
	endif

	config MODULES
		def_bool y
		option modules

	config AFTER_1
		def_tristate y if m

	if m
	config AFTER_2
		def_tristate y
	endif

Fix the issue by rewriting 'm' in menu_finalize() instead. This function
runs after parsing and is the proper place to do it. The following
existing code in conf_parse() in zconf.y ensures that the modules symbol
exists at that point:

	if (!modules_sym)
		modules_sym = sym_find( "n" );

	...

	menu_finalize(&rootmenu);

The following tests were done to ensure no functional changes for
configurations that don't reference 'm' before the modules symbol:

	- zconfdump(stdout) was run with ARCH=x86 and ARCH=arm before
	  and after the change and verified to produce identical output.
	  This function prints all symbols, choices, and menus together
	  with their properties and their dependency expressions. A
	  rewritten 'm' appears as 'm && MODULES'.

	  A small annoyance is that the assert(len != 0) in xfwrite()
	  needs to be disabled in order to use zconfdump(), because it
	  chokes on e.g. 'default ""'.

	- The Kconfiglib test suite was run to indirectly verify that
	  alldefconfig, allyesconfig, allnoconfig, and all defconfigs in
	  the kernel still generate the same final .config.

	- Valgrind was used to check for memory errors and (new) memory
	  leaks.
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      f77850d3
    • U
      kconfig: Clarify expression rewriting · fa8cedae
      由 Ulf Magnusson 提交于 
      menu_finalize() is one of the more opaque parts of Kconfig, and I need
to make some changes to it to fix an issue related to modules. Add some
comments related to expression rewriting and dependency propagation as a
review aid. They will also help other people trying to understand the
code.
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      fa8cedae
    • U
      kconfig: Rename menu_check_dep() to rewrite_m() · 9a826842
      由 Ulf Magnusson 提交于 
      More directly describes the only thing it does.
Signed-off-by: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9a826842
  15. 12 12月, 2017 1 次提交
  17. 07 12月, 2017 3 次提交
  19. 04 12月, 2017 1 次提交
  21. 03 12月, 2017 3 次提交