06 Sep, 2019

1 commit

  • KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
    options for GCC, but now it is a historical misnomer since we use it
    also for Clang, DTC, and even kernel-doc.

    Rename it to more sensible, shorter KBUILD_EXTRA_WARN.

    For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
    supported (but not advertised in the documentation).

    I also fixed up 'make help', and updated the documentation.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Nathan Chancellor
    Reviewed-by: Nick Desaulniers
    Reviewed-by: Sedat Dilek

    Masahiro Yamada
     

14 Aug, 2019

1 commit

  • We generally expect bison to create not only a C file, but also a
    header, which will be included from the lexer.

    Currently, Kbuild generates them in separate rules. So, for instance,
    when building Kconfig, you will notice bison is invoked twice:

    HOSTCC scripts/kconfig/conf.o
    HOSTCC scripts/kconfig/confdata.o
    HOSTCC scripts/kconfig/expr.o
    LEX scripts/kconfig/lexer.lex.c
    YACC scripts/kconfig/parser.tab.h
    HOSTCC scripts/kconfig/lexer.lex.o
    YACC scripts/kconfig/parser.tab.c
    HOSTCC scripts/kconfig/parser.tab.o
    HOSTCC scripts/kconfig/preprocess.o
    HOSTCC scripts/kconfig/symbol.o
    HOSTLD scripts/kconfig/conf

    Make handles such cases nicely in pattern rules [1]. Merge the two
    rules so that one invokcation of bison can generate both of them.

    HOSTCC scripts/kconfig/conf.o
    HOSTCC scripts/kconfig/confdata.o
    HOSTCC scripts/kconfig/expr.o
    LEX scripts/kconfig/lexer.lex.c
    YACC scripts/kconfig/parser.tab.[ch]
    HOSTCC scripts/kconfig/lexer.lex.o
    HOSTCC scripts/kconfig/parser.tab.o
    HOSTCC scripts/kconfig/preprocess.o
    HOSTCC scripts/kconfig/symbol.o
    HOSTLD scripts/kconfig/conf

    [1] Pattern rule

    GNU Make manual says:
    "Pattern rules may have more than one target. Unlike normal rules,
    this does not act as many different rules with the same prerequisites
    and recipe. If a pattern rule has multiple targets, make knows that
    the rule's recipe is responsible for making all of the targets. The
    recipe is executed only once to make all the targets. When searching
    for a pattern rule to match a target, the target patterns of a rule
    other than the one that matches the target in need of a rule are
    incidental: make worries only about giving a recipe and prerequisites
    to the file presently in question. However, when this file's recipe is
    run, the other targets are marked as having been updated themselves."

    https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

18 May, 2019

1 commit

  • Currently, the Kbuild core manipulates header search paths in a crazy
    way [1].

    To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
    the search paths in the srctree. Some Makefiles are already written in
    that way, but not all. The goal of this work is to make the notation
    consistent, and finally get rid of the gross hacks.

    Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
    ("kbuild: do not drop -I without parameter").

    [1]: https://patchwork.kernel.org/patch/9632347/

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

05 May, 2018

1 commit


07 Apr, 2018

3 commits

  • Files generated by if_changed* must be added to 'targets' to include
    *.cmd files. Otherwise, they would be regenerated every time.

    The build system automatically adds objects to 'targets' where
    appropriate, such as obj-y, extra-y, etc. but does nothing for
    intermediate files. So, each Makefile needs to add them by itself.

    There are some common cases where objects are generated by chained
    rules. Lexers and parsers are compiled like follows:

    %.lex.o
    Acked-by: Frank Rowand

    Masahiro Yamada
     
  • Now that the kernel build supports flex and bison, remove the _shipped
    files and generate them during the build instead.

    There are no more shipped lexer and parser, so I ripped off the rules
    in scripts/Malefile.lib that were used for REGENERATE_PARSERS.

    The genksyms parser has ambiguous grammar, which would emit warnings:

    scripts/genksyms/parse.y: warning: 9 shift/reduce conflicts [-Wconflicts-sr]
    scripts/genksyms/parse.y: warning: 5 reduce/reduce conflicts [-Wconflicts-rr]

    They are normally suppressed, but displayed when W=1 is given.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers,
    respectively. Clean them up globally from the top Makefile.

    Some of the final host programs those lexer/parser are linked into
    are necessary for building external modules, but the intermediates
    are unneeded. They can be cleaned away by 'make clean' instead of
    'make mrproper'.

    Signed-off-by: Masahiro Yamada
    Acked-by: Frank Rowand

    Masahiro Yamada
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

20 Aug, 2017

1 commit

  • It turns out that gperf-3.1 changed types in the generated code in ways
    that aren't even trivially detectable without having to generate a test-file.

    It's just not worth using tools and libraries from clowns that don't
    understand or care about compatibility. So get rid of gperf.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 Jan, 2012

1 commit


10 Jun, 2011

2 commits


17 Mar, 2011

1 commit


13 Oct, 2007

1 commit

  • When enabling GENERATE_PARSER the genksyms Makefile
    failed to create _shipped version of generated files.

    Modifying keywords.gperf failed to cause a rebuild
    of genksyms.
    Fixed by specifying keywowrds .c as explicit prerequisite
    of the lexer.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds