Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. May 03, 2019
  3. Apr 30, 2019
  5. Apr 09, 2019
  7. Apr 08, 2019
  9. Apr 06, 2019
    • Christoph Hellwig's avatar
      block: remove CONFIG_LBDAF · 72deb455
      Christoph Hellwig authored 
      
Currently support for 64-bit sector_t and blkcnt_t is optional on 32-bit
architectures.  These types are required to support block device and/or
file sizes larger than 2 TiB, and have generally defaulted to on for
a long time.  Enabling the option only increases the i386 tinyconfig
size by 145 bytes, and many data structures already always use
64-bit values for their in-core and on-disk data structures anyway,
so there should not be a large change in dynamic memory usage either.

Dropping this option removes a somewhat weird non-default config that
has cause various bugs or compiler warnings when actually used.

Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      72deb455
  11. Apr 01, 2019
  13. Mar 25, 2019
    • Sean Christopherson's avatar
      docs: Clarify the usage and sign-off requirements for Co-developed-by · 24a2bb90
      Sean Christopherson authored 
      
The documentation for Co-developed-by is a bit light on details, e.g. it
doesn't explicitly state that:

  - Multiple Co-developed-by tags are perfectly acceptable
  - Co-developed-by and Signed-off-by must be paired together
  - SOB ordering should still follow standard sign-off procedure

Lack of explicit direction has resulted in developers taking a variety
of approaches, often lacking any intent whatsoever, e.g. scattering SOBs
willy-nilly, collecting them all at the end or the beginning, etc...
Tweak the wording to make it clear that multiple co-authors are allowed,
and document the expectation that standard sign-off procedures are to
be followed.

The use of "original author" has also led to confusion as many patches
don't have just one "original" author, e.g. when multiple developers
are involved from the genesis of the patch.  Remove all usage of
"original" and instead call out that Co-developed-by is simply a way to
provide attribution in addition to the From tag, i.e. neither tag is
intended to imply anything with regard to who did what.

Provide examples to (hopefully) eliminate any ambiguity.

Cc: Tobin C. Harding <me@tobin.cc>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Joe Perches <joe@perches.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Niklas Cassel <niklas.cassel@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      24a2bb90
    • Tom Levy's avatar
      docs: remove spaces from shell variable assignment · 4318f9bb
      Tom Levy authored 
      
The instructions for generating patches are given as shell commands
with variables as placeholders. They use the syntax "SRCTREE= linux",
which is wrong for the Bourne shell family (it runs the command
"linux" with the variable "SRCTREE" set to the empty string).

Remove the spaces to avoid confusion. This breaks the pretty alignment
but helps new contributors who try to run the commands as written.

Signed-off-by: default avatarTom Levy <tomlevy93@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      4318f9bb
  15. Mar 18, 2019
  17. Mar 08, 2019
  19. Mar 04, 2019
  21. Feb 22, 2019
  23. Feb 17, 2019
  25. Feb 11, 2019
    • Jonathan Neuschäfer's avatar
      docs: process: Remove outdated info about -git patches · 2c71d305
      Jonathan Neuschäfer authored 
      As can be seen by clicking around the timeline on web.archive.org[1],
there were no -git patches/tarballs on kernel.org since release 3.1.

[1]: https://web.archive.org/web/20111103073843/http://www.kernel.org/



Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      2c71d305
    • Thomas Gleixner's avatar
      module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity · bf7fbeea
      Thomas Gleixner authored 
      The original MODULE_LICENSE string for kernel modules licensed under the
GPL v2 (only / or later) was simply "GPL", which was - and still is -
completely sufficient for the purpose of module loading and checking
whether the module is free software or proprietary.

In January 2003 this was changed with commit 3344ea3ad4b7 ("[PATCH]
MODULE_LICENSE and EXPORT_SYMBOL_GPL support"). This commit can be found in
the history git repository which holds the 1:1 import of Linus' bitkeeper
repository:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=3344ea3ad4b7c302c846a680dbaeedf96ed45c02



The main intention of the patch was to refuse linking proprietary modules
against symbols exported with EXPORT_SYMBOL_GPL() at module load time.

As a completely undocumented side effect it also introduced the distinction
between "GPL" and "GPL v2" MODULE_LICENSE() strings:

 *      "GPL"                           [GNU Public License v2 or later]
 *      "GPL v2"                        [GNU Public License v2]
 *      "GPL and additional rights"     [GNU Public License v2 rights and more]
 *      "Dual BSD/GPL"                  [GNU Public License v2
 *                                       or BSD license choice]
 *      "Dual MPL/GPL"                  [GNU Public License v2
 *                                       or Mozilla license choice]

This distinction was and still is wrong in several aspects:

 1) It broke all modules which were using the "GPL" string in the
    MODULE_LICENSE() already and were licensed under GPL v2 only.

    A quick license scan over the tree at that time shows that at least 480
    out of 1484 modules have been affected by this change back then. The
    number is probably way higher as this was just a quick check for
    clearly identifiable license information.

    There was exactly ONE instance of a "GPL v2" module license string in
    the kernel back then - drivers/net/tulip/xircom_tulip_cb.c which
    otherwise had no license information at all. There is no indication
    that the change above is any way related to this driver. The change
    happend with the 2.4.11 release which was on Oct. 9 2001 - so quite
    some time before the above commit. Unfortunately there is no trace on
    the intertubes to any discussion of this.

 2) The dual licensed strings became ill defined as well because following
    the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
    rights) MODULE_LICENSE strings would either require those dual licensed
    modules to be licensed under GPL v2 or later or just be unspecified for
    the dual licensing case. Neither choice is coherent with the GPL
    distinction.

Due to the lack of a proper changelog and no real discussion on the patch
submission other than a few implementation details, it's completely unclear
why this distinction was introduced at all. Other than the comment in the
module header file exists no documentation for this at all.

From a license compliance and license scanning POV this distinction is a
total nightmare.

As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
conflicting with the actual license in the source code (either SPDX or
license boilerplate/reference). A comparison between the scan of the
history tree and a scan of current Linus tree shows to the extent that the
git rename detection over Linus tree grafted with the history tree is
halfways complete that almost none of the files which got broken in 2003
have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
480 known instances from the conflicting 2800 of today more than 25% of the
module authors got it wrong and it's a high propability that a large
portion of the rest just got it right by chance.

There is no value for the module loader to convey the detailed license
information as the only decision to be made is whether the module is free
software or not.

The "and additional rights", "BSD" and "MPL" strings are not conclusive
license information either. So there is no point in trying to make the GPL
part conclusive and exact. As shown above it's already non conclusive for
dual licensing and incoherent with a large portion of the module source.

As an unintended side effect this distinction causes a major headache for
license compliance, license scanners and the ongoing effort to clean up the
license mess of the kernel.

Therefore remove the well meant, but ill defined, distinction between "GPL"
and "GPL v2" and document that:

  - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
    (without a distinction of 'only' and 'or later') and is therefore kernel
    license compliant.

  - None of the MODULE_LICENSE strings can be used for expressing or
    determining the exact license

  - Their sole purpose is to decide whether the module is free software or
    not.

Add a MODULE_LICENSE subsection to the license rule documentation as well.

Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
Acked-by: default avatarJoe Perches <joe@perches.com>
[jc: Did s/merily/merely/ ]
Acked-by: default avatarJessica Yu <jeyu@kernel.org>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      bf7fbeea
  27. Feb 01, 2019
  29. Jan 21, 2019
  31. Jan 14, 2019
  33. Jan 07, 2019
  35. Jan 04, 2019
  37. Dec 06, 2018
  39. Nov 20, 2018
  41. Oct 22, 2018
  43. Oct 18, 2018
  45. Sep 30, 2018