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
     

16 Apr, 2016

1 commit

  • Four instances of incorrect usage of non-static "inline" crept up
    in arch/x86, all trivial; cleaning them up:

    EVT_TO_HPET_DEV() - made static, it is only used in kernel/hpet.c

    Debug version of check_iommu_entries() is an __init function.
    Non-debug dummy empty version of it is declared "inline" instead -
    which doesn't help to eliminate it (the caller is in a different unit,
    inlining doesn't happen).
    Switch to non-inlined __init function, which does eliminate it
    (by discarding it as part of __init section).

    crypto/sha-mb/sha1_mb.c: looks like they just forgot to add "static"
    to their two internal inlines, which emitted two unused functions into
    vmlinux.

    text data bss dec hex filename
    95903394 20860288 35991552 152755234 91adc22 vmlinux_before
    95903266 20860288 35991552 152755106 91adba2 vmlinux

    Signed-off-by: Denys Vlasenko
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Link: http://lkml.kernel.org/r/1460739626-12179-1-git-send-email-dvlasenk@redhat.com
    Signed-off-by: Ingo Molnar

    Denys Vlasenko
     

10 May, 2011

1 commit


27 Aug, 2010

1 commit

  • We are using a very simple sort routine which sorts the .iommu_table
    array in the order of dependencies. Specifically each structure
    of iommu_table_entry has a field 'depend' which contains the function
    pointer to the IOMMU that MUST be run before us. We sort the array
    of structures so that the struct iommu_table_entry with no
    'depend' field are first, and then the subsequent ones are the
    ones for which the 'depend' function has been already invoked
    (in other words, precede us).

    Using the kernel's version 'sort', which is a mergeheap is
    feasible, but would require making the comparison operator
    scan recursivly the array to satisfy the "heapify" process: setting the
    levels properly. The end result would much more complex than it should
    be an it is just much simpler to utilize this simple sort routine.

    Signed-off-by: Konrad Rzeszutek Wilk
    LKML-Reference:
    CC: H. Peter Anvin
    CC: Fujita Tomonori
    Signed-off-by: H. Peter Anvin

    Konrad Rzeszutek Wilk