Currently gen_init_cpio -d <timestamp> is applied to symlinks,
directories and special files. These files are created by
gen_init_cpio from their description. Without <timestamp> option
current time(NULL) is used. And regular files that go in initramfs
are created before cpio generation, so their mtime(s) are preserved.

This is usually not an issue as reproducible builds should rebuild
everything in the distribution, including binaries, configs and whatever
other regular files may find their way into kernel's initramfs.

On the other hand, gen_initramfs.sh usage claims:
>	-d <date>      Use date for all file mtime values

Ar Arista initramfs files are managed with version control system
that preserves mtime. Those are configs, boot parameters, init scripts,
version files, platform-specific files, probably some others, too.

While it's certainly possible to work this around by copying the file
into temp directory and adjusting mtime prior to gen_init_cpio call,
I don't see why it needs workarounds.

The intended user of -d <date> option is the one that needs to create
a reproducible build, see commit a8b8017c ("initramfs: Use
KBUILD_BUILD_TIMESTAMP for generated entries"). If a user wants
the build reproduction, they use -d <date>, which can be set on all
types of files, without surprising exceptions and workarounds.
Let's KISS here and just apply the time that user specified
with -d option.
Based-on-a-patch-by: Baptiste Covolato <baptiste@arista.com>
Link: https://lore.kernel.org/lkml/20181025215133.20138-1-baptiste@arista.com/Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, Kbuild follows the logical chain of directories for the O=
option, just like 'cd' (or 'realpath --logical') does.

Example:

    $ mkdir -p /tmp/a /tmp/x/y
    $ ln -s /tmp/x/y /tmp/a/b
    $ realpath /tmp/a/b/..
    /tmp/x
    $ realpath --logical /tmp/a/b/..
    /tmp/a
    $ make O=/tmp/a/b/.. defconfig
    make[1]: Entering directory '/tmp/a'
      [snip]
    make[1]: Leaving directory '/tmp/a'

'make O=/tmp/a/b/.. defconfig' creates the kernel configuration in
/tmp/a instead of /tmp/x despite /tmp/a/b/.. resolves to /tmp/x.

This is because Kbuild internally uses the 'cd ... && pwd' for the
path resolution, but this behavior is not predictable for users.
Additionally, it is not consistent with how the Kbuild handles the
M= option or GNU Make works with 'make -C /tmp/a/b/..'.

Using the physical directory structure for the O= option seems more
reasonable.

The comment says "expand a shell special character '~'", but it has
already been expanded to the home directory in the command line.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Add detailed documentation for scripts/check-uapi.sh.
Signed-off-by: John Moon <quic_johmoo@quicinc.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

While the kernel community has been good at maintaining backwards
compatibility with kernel UAPIs, it would be helpful to have a tool
to check if a commit introduces changes that break backwards
compatibility.

To that end, introduce check-uapi.sh: a simple shell script that
checks for changes to UAPI headers using libabigail.

libabigail is "a framework which aims at helping developers and
software distributors to spot some ABI-related issues like interface
incompatibility in ELF shared libraries by performing a static
analysis of the ELF binaries at hand."

The script uses one of libabigail's tools, "abidiff", to compile the
changed header before and after the commit to detect any changes.

abidiff "compares the ABI of two shared libraries in ELF format. It
emits a meaningful report describing the differences between the two
ABIs."

The script also includes the ability to check the compatibility of
all UAPI headers across commits. This allows developers to inspect
the stability of the UAPIs over time.
Signed-off-by: John Moon <quic_johmoo@quicinc.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When reviewing patches, it looks much nicer to have some changes shown
before others, which allow better understanding of the patch before the
the .c files reviewing.

Introduce a default git.orderFile, in order to help developers getting the
best ordering easier.
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When KCONFIG_WERROR env variable is set treat unmet direct
symbol dependency as a terminal condition (error).
Suggested-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

EditorConfig is a specification to define the most basic code formatting
stuff, and it's supported by many editors and IDEs, either directly or
via plugins, including VSCode/VSCodium, Vim, emacs and more.

It allows to define formatting style related to indentation, charset,
end of lines and trailing whitespaces. It also allows to apply different
formats for different files based on wildcards, so for example it is
possible to apply different configs to *.{c,h}, *.py and *.rs.

In linux project, defining a .editorconfig might help to those people
that work on different projects with different indentation styles, so
they cannot define a global style. Now they will directly see the
correct indentation on every fresh clone of the project.

See https://editorconfig.orgCo-developed-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Acked-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Tested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When using a custom location for kernel config files this merge config
command fails as it doesn't use the configuration set with
KCONFIG_CONFIG.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Passing NULL to free() is allowed and is a no-op.

Remove redundant NULL pointer checks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Remove the unreachable code detected by clang.

  $ make HOSTCC=clang HOSTCFLAGS=-Wunreachable-code defconfig
    [ snip ]
  scripts/kconfig/expr.c:1134:2: warning: code will never be executed [-Wunreachable-code]
          printf("[%dgt%d?]", t1, t2);
          ^~~~~~
  1 warning generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

menu_has_help() and menu_get_help() functions are only used within
menu_get_ext_help().

Squash them into menu_get_ext_help(). It revealed the if-conditional
in menu_get_help() was unneeded, as menu_has_help() has already checked
that menu->help is not NULL.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Separate out the duplicated code to mnconf-common.c.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

$(addprefix ) is slightly shorter and more intuitive.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Add objects to obj-y in a more straightforward way.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Currently, vdso-image-*.c, vdso*.so, vdso*.so.dbg are not cleaned
because 'make clean' does not include include/config/auto.conf,
resulting in $(vdso_img-y) being empty.

Add the build artifacts to 'targets' unconditionally.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Now compilers can recognize fatal() never returns.

While GCC 4.5 dropped support for -Wunreachable-code, Clang is capable
of detecting the unreachable code.

  $ make HOSTCC=clang HOSTCFLAGS=-Wunreachable-code-return
      [snip]
    HOSTCC  scripts/mod/modpost.o
  scripts/mod/modpost.c:520:11: warning: 'return' will never be executed [-Wunreachable-code-return]
                          return 0;
                                 ^
  scripts/mod/modpost.c:477:10: warning: 'return' will never be executed [-Wunreachable-code-return]
                  return 0;
                         ^
  2 warnings generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

This initializer was added to avoid -Wmaybe-uninitialized (gcc) and
-Wsometimes-uninitialized (clang) warnings.

Now that compilers recognize fatal() never returns, it is unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

The function fatal() never returns because modpost_log() calls exit(1)
when LOG_FATAL is passed.

Inform compilers of this fact so that unreachable code flow can be
identified at compile time.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

This attribute must be added to the function declaration in a header
for comprehensive checking of all the callsites.

Fixes: 6d9a89ea ("kbuild: declare the modpost error functions as printf like")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

When using the -dtbs syntax, you need to list the base first, as
follows:

    foo-dtbs := foo_base.dtb foo_overlay1.dtbo foo_overlay2.dtbo
    dtb-y := foo.dtb

You cannot do this arrangement:

    foo-dtbs := foo_overlay1.dtbo foo_overlay2.dtbo foo_base.dtb

This restriction comes from $(firstword ...) in the current
implementation, but it is unneeded to rely on the order in the
-dtbs syntax.

Instead, you can simply determine the base by the suffix because
the base (*.dtb) and overlays (*.dtbo) use different suffixes.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

In 2017, the dpkg suite introduced the rootless builds support with the
following commits:

  - 2436807c87b0 ("dpkg-deb: Add support for rootless builds")
  - fca1bfe84068 ("dpkg-buildpackage: Add support for rootless builds")

This feature is available in the default dpkg on Debian 10 and Ubuntu
20.04.

Remove the old method.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Commit f5016932 ("module.h: split out the EXPORT_SYMBOL into
export.h") appropriately separated EXPORT_SYMBOL into <linux/export.h>
because modules and EXPORT_SYMBOL are orthogonal; modules are symbol
consumers, while EXPORT_SYMBOL are used by symbol providers, which
may not be necessarily a module.

However, that commit also relocated THIS_MODULE. As explained in the
commit description, the intention was to define THIS_MODULE in a
lightweight header, but I do not believe <linux/export.h> was the
best location because EXPORT_SYMBOL and THIS_MODULE are unrelated.

Move it to another lightweight header, <linux/init.h>. The reason for
choosing <linux/init.h> is to make <linux/moduleparam.h> self-contained
without relying on <linux/linkage.h> incorrectly including
<linux/export.h>.

With this adjustment, the role of <linux/export.h> becomes clearer as
it only defines EXPORT_SYMBOL.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>

When a default property is missing in an int or hex symbol, it defaults
to an empty string, which is not a valid symbol value.

It results in an incorrect .config, and can also lead to an infinite
loop in scripting.

Use "0" for int and "0x0" for hex as a default value.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>

This is used only for initializing other variables.

Use the empty string "" directly.

Please note newval.tri is unused for S_INT/HEX/STRING.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

A little more janitorial work after commit cf8e8658 ("arch: Remove
Itanium (IA-64) architecture").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

KCONFIG_WARN_UNKNOWN_SYMBOLS=1 and KCONFIG_WERROR=1 are descriptive
and suitable in scripting, but typing them from the command line can
be tedious.

Associate them with KBUILD_EXTRA_WARN (and the W= shorthand).

Support a new letter 'c' to enable extra checks in Kconfig. You can
still manage compiler warnings (W=1) and Kconfig warnings (W=c)
independently.

Reuse the letter 'e' to turn Kconfig warnings into errors.

As usual, you can combine multiple letters in KCONFIG_EXTRA_WARN.

  $ KCONFIG_WARN_UNKNOWN_SYMBOLS=1 KCONFIG_WERROR=1 make defconfig

can be shortened to:

  $ KBUILD_EXTRA_WARN=ce make defconfig

or, even shorter:

  $ make W=ce defconfig
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

The rpm-pkg and deb-pkg targets have transitioned to using 'git archive'
for tarball creation.

Although the old cmd_src_tar is still used by snap-pkg, there is no need
to pack and unpack a tarball solely for passing the source to snapcraft.

Instead, you can use 'source-type: local' to tell the source location to
snapcraft.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

It is done for the same reasons as 4243afdb does it for builddeb:
always runs make modules to install modules.builtin* files, which are
needed for e.g. initramfs-tools or LTP testing tool.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The shell variable $dirs is not used any more since 1fc90958
("kbuild: tar-pkg: use tar rules in scripts/Makefile.package"),
therefore remove it".

Fixes: 1fc90958 ("kbuild: tar-pkg: use tar rules in scripts/Makefile.package")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Make the while-loop code a little more readable.

The gain is that "CONFIG_FOO" without '=' is warned as unexpected data.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, any string starting "is not set" disables a CONFIG option.

For example, "# CONFIG_FOO is not settled down" is accepted as valid
input, functioning the same as "# CONFIG_FOO is not set". It is a
long-standing oddity.

Check the line against the exact pattern "is not set".
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, newline characters are stripped away in multiple places
on the caller.

Doing that in the callee is helpful for further cleanups.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as
a valid input, but conf_read_simple() duplicates similar code to handle
them. Factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The 'else' arm here is unreachable in practical use cases.

include/config/auto.conf does not include "# CONFIG_... is not set"
line unless it is manually hacked.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, when an input line starts with '#', (line + 2) is passed to
memcmp() without checking line[1].

It means that line[1] can be any arbitrary character. For example,
"#KCONFIG_FOO is not set" is accepted as valid input, functioning the
same as "# CONFIG_FOO is not set".

More importantly, this can potentially lead to a buffer overrun if
line[1] == '\0'. It occurs if the input only contains '#', as
(line + 2) points to an uninitialized buffer.

Check line[1], and skip the line if it is not a space.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

xrealloc() never returns NULL as it is checked in the callee.

This is a left-over of commit d717f24d ("kconfig: add xrealloc()
helper").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The long version --rules-file and --jobs are available since 1.18.8
while their short analogues -R and -j have been added since 1.14.7.

The option --rules-file the way it works currently was introduced in the
commit 5cd52673aabdf5eaa58181972119a41041fc85f2 of dpkg dated 23.07.18
with the following changelog entry:

* Fix dpkg-buildpackage option --rules-file parsing. It was trying to parse
  it as --rules-target, which due to the ordering was a no-op.

The current behavior of the long version --rules-file is guaranteed to
be in use starting 1.19.1 and might cause build failures for some
versions newer than 1.18.8 even in spite of being documented that way.
Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When a user-supplied value is out of range, (NEW) and an incorrect default
value are shown.

[Test Kconfig]

  config FOO
          int "foo"
          range 10 20

[Test .config]

  CONFIG_FOO=30

[Result without this fix]

  $ make config
  *
  * Main menu
  *
  foo (FOO) [10] (NEW)

[Result with this fix]

  $ make config
  *
  * Main menu
  *
  foo (FOO) [20]

Currently, the SYMBOL_DEF_USER is cleared if the user input does not
reside within the range. Kconfig forgets the initial value 30, and
prints (NEW) and an incorrect default [10].

Kconfig should remember the user's input. The default should be [20]
because the user's input, 30, is closer to the upper limit of the range.

Please note it will not show up in "make oldconfig" because it is no
longer considered as a new symbol. It also fixes the inconsistent
behavior in listnewconfig/helpnewconfig.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

getopt_long() is used by various tools in the kernel (e.g. Kconfig).

It should be fine to use it all the time.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>