linux.git/Documentation/kbuild, branch v4.18

kbuild: document the KBUILD_KCONFIG env. variable

2018-07-06T13:04:01+00:00

Add usage info for the Kbuild environment variable KBUILD_KCONFIG.

Signed-off-by: Randy Dunlap 
Reviewed-by: Cao jin 
Signed-off-by: Masahiro Yamada

kconfig: update user kconfig tools doc.

2018-07-06T13:04:01+00:00

Update Documentation/kbuild/kconfig.txt, which mostly contains
user help for using the kernel config tools.

- Add mention of 'nconfig' embedded help text.
- Make the section on new config symbols readable.
- Correct how to find menuconfig search help.
- Add section on 'nconfig' usage.
- Mention that gconfig has multiple viewing modes/options.

Signed-off-by: Randy Dunlap 
Signed-off-by: Masahiro Yamada

kbuild: delete INSTALL_FW_PATH from kbuild documentation

2018-07-06T12:58:33+00:00

Removed Kbuild documentation for INSTALL_FW_PATH.

The kbuild symbol INSTALL_FW_PATH was removed from Kbuild tools in
September 2017 (for 4.14) but the symbol was not deleted from
the kbuild documentation, so do that now.

Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
Signed-off-by: Randy Dunlap 
Cc: stable@vger.kernel.org # 4.14+
Cc: Greg Kroah-Hartman 
Signed-off-by: Masahiro Yamada

kbuild: update ARCH alias info for sparc

2018-07-06T12:58:33+00:00

The supported alias for building sparc 32-bit is "sparc32",
not "sparc", so update the alias documentation for that.
Just using "sparc" produces a 64-bit config file.

Signed-off-by: Randy Dunlap 
Acked-by: David S. Miller 
Signed-off-by: Masahiro Yamada

kbuild: update ARCH alias info for sh

2018-07-06T12:58:33+00:00

In Kbuild documentation, add alias for 64-bit sh ARCH ("sh64")
to the list of ARCH aliases.

Signed-off-by: Randy Dunlap 
Signed-off-by: Masahiro Yamada

kconfig: document Kconfig source file comments

2018-06-25T14:21:14+00:00

I saw this type of Kconfig construct on LKML:

config SYMBOOL
	#bool "prompt string"
	default y

and wondered what it does.  Then I wondered if '#' comments are
even documented.  They aren't, so add a little doc for that.

Ah, good.  kconfig says:
arch/x86/Kconfig:2942:warning: config symbol defined without type

Signed-off-by: Randy Dunlap 
Signed-off-by: Masahiro Yamada

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

2018-06-14T03:21:18+00:00

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_NONE is not set
  # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one.  This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_STACKPROTECTOR=y
  CONFIG_STACKPROTECTOR_STRONG=y
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: Masahiro Yamada 
Signed-off-by: Linus Torvalds

Documentation: kconfig: add recommended way to describe compiler support

2018-06-11T00:16:28+00:00

It would be nice if the source code is written in the same style.
This proposes the convention for describing the compiler capability
in Kconfig.

Signed-off-by: Masahiro Yamada

Documentation: kconfig: document a new Kconfig macro language

2018-05-28T18:31:19+00:00

Add a document for the macro language introduced to Kconfig.

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.  By moving the
compiler capability tests to Kconfig, features unsupported by the
compiler will be hidden automatically.

This change was strongly prompted by Linus Torvalds.  You can find
his suggestions [1] [2] in ML.  The original idea was to add a new
attribute with 'option shell=...', but I found more generalized text
expansion would make Kconfig more powerful and lovely.  The basic
ideas are from Make, but there are some differences.

[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Randy Dunlap

kconfig: reference environment variables directly and remove 'option env='

2018-05-28T18:28:58+00:00

To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
          string
          default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook