31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 or at your option any
    later version this program is distributed in the hope that it will
    be useful but without any warranty without even the implied warranty
    of merchantability or fitness for a particular purpose see the gnu
    general public license for more details you should have received a
    copy of the gnu general public license along with this program if
    not write to the free software foundation inc 675 mass ave cambridge
    ma 02139 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 77 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Armijn Hemel
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.837555891@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

22 Aug, 2017

1 commit


19 Mar, 2017

1 commit


25 Dec, 2016

1 commit


13 Dec, 2016

1 commit


17 Jun, 2015

1 commit

  • The perf.c code depends on CONFIG_64BIT, so it is either built-in
    or absent. It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.

    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future. If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing. Aside from it not making sense, it also
    causes a ~10% increase in CPP overhead due to module.h having a
    large list of headers itself -- for example compare line counts:

    device_initcall() and
    20238 arch/parisc/kernel/perf.i

    module_init() and
    22194 arch/parisc/kernel/perf.i

    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero. Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.

    Cc: "James E.J. Bottomley"
    Cc: Helge Deller
    Cc: linux-parisc@vger.kernel.org
    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

17 Oct, 2010

1 commit

  • The parisc version of the perf code is sufficiently
    protected by its own spinlock, no need to use the BKL.

    Signed-off-by: Arnd Bergmann
    Cc: Kyle McMartin
    Cc: Helge Deller
    Cc: "James E.J. Bottomley"
    Cc: linux-parisc@vger.kernel.org

    Arnd Bergmann
     

09 Nov, 2009

1 commit

  • something-bility is spelled as something-blity
    so a grep for 'blit' would find these lines

    this is so trivial that I didn't split it by subsystem / copy
    additional maintainers - all changes are to comments
    The only purpose is to get fewer false positives when grepping
    around the kernel sources.

    Signed-off-by: Dirk Hohndel
    Signed-off-by: Jiri Kosina

    Dirk Hohndel
     

06 Jan, 2009

1 commit


03 Jul, 2008

1 commit


23 May, 2007

2 commits


13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    [akpm@osdl.org: sparc64 fix]
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

31 Mar, 2006

1 commit


23 Jan, 2006

2 commits


12 Jan, 2006

1 commit


11 Jan, 2006

1 commit


18 Nov, 2005

1 commit


22 Oct, 2005

1 commit


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