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
     

24 Aug, 2017

1 commit


22 Jun, 2017

1 commit

  • Originally, generated-y and genhdr-y had different meaning, like
    follows:

    - generated-y: generated headers (other than asm-generic wrappers)
    - header-y : headers to be exported
    - genhdr-y : generated headers to be exported (generated-y + header-y)

    Since commit fcc8487d477a ("uapi: export all headers under uapi
    directories"), headers under UAPI directories are all exported.
    So, there is no more difference between generated-y and genhdr-y.

    We see two users of genhdr-y, arch/{arm,x86}/include/uapi/asm/Kbuild.
    They generate some headers in arch/{arm,x86}/include/generated/uapi/asm
    directories, which are obviously exported.

    Replace them with generated-y, and abolish genhdr-y.

    Signed-off-by: Masahiro Yamada
    Acked-by: Nicolas Dichtel

    Masahiro Yamada
     

07 Jul, 2016

1 commit

  • When a header file is removed from generic-y (often accompanied by the
    addition of an arch specific header), the generated wrapper file will
    persist, and in some cases may still take precedence over the new arch
    header.

    For example commit f1fe2d21f4e1 ("MIPS: Add definitions for extended
    context") removed ucontext.h from generic-y in arch/mips/include/asm/,
    and added an arch/mips/include/uapi/asm/ucontext.h. The continued use of
    the wrapper when reusing a dirty build tree resulted in build failures
    in arch/mips/kernel/signal.c:

    arch/mips/kernel/signal.c: In function ‘sc_to_extcontext’:
    arch/mips/kernel/signal.c:142:12: error: ‘struct ucontext’ has no member named ‘uc_extcontext’
    return &uc->uc_extcontext;
    ^
    Fix by detecting and removing wrapper headers in generated header
    directories that do not correspond to a filename in generic-y, genhdr-y,
    or the newly introduced generated-y.

    Reported-by: Jacek Anaszewski
    Reported-by: Hauke Mehrtens
    Reported-by: Heinrich Schuchardt
    Signed-off-by: James Hogan
    Acked-by: Arnd Bergmann
    Acked-by: Florian Fainelli
    Cc: linux-arch@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: Paul Burton
    Cc: linux-kbuild@vger.kernel.org
    Cc: Ralf Baechle
    Cc: Michal Marek
    Link: http://lkml.kernel.org/r/1466808144-23209-3-git-send-email-james.hogan@imgtec.com
    Signed-off-by: Thomas Gleixner

    James Hogan
     

10 Jun, 2014

1 commit


17 Oct, 2012

1 commit


09 Jun, 2011

1 commit


03 May, 2011

1 commit


29 Apr, 2011

1 commit

  • There is an increasing amount of header files
    shared between individual architectures in asm-generic.
    To avoid a lot of dummy wrapper files that just
    include the corresponding file in asm-generic provide
    some basic support in kbuild for this.

    With the following patch an architecture can maintain
    a list of files in the file arch/$(ARCH)/include/asm/Kbuild

    To use a generic file just add:

    generic-y +=

    For each file listed kbuild will generate the necessary
    wrapper in arch/$(ARCH)/include/generated/asm.

    When installing userspace headers a wrapper is likewise created.

    The original inspiration for this came from the unicore32
    patchset - although a different method is used.

    The patch includes several improvements from Arnd Bergmann.
    Michael Marek contributed Makefile.asm-generic.

    Remis Baima did an intial implementation along to achive
    the same - see https://patchwork.kernel.org/patch/13352/

    Signed-off-by: Sam Ravnborg
    Acked-by: Guan Xuetao
    Tested-by: Guan Xuetao
    Acked-by: Arnd Bergmann
    Cc: Remis Lima Baima
    Signed-off-by: Michal Marek

    Sam Ravnborg