linux-toradex.git/Documentation/process, branch v6.11 Linux kernel for Apalis and Colibri modules docs: netdev: document guidance on cleanup.h 2024-09-05T09:00:35+00:00 Jakub Kicinski kuba@kernel.org 2024-08-30T17:14:42+00:00 c82299fbbccecf5866bdc3fa9cc46d5c6f5005ad Document what was discussed multiple times on list and various virtual / in-person conversations. guard() being okay in functions <= 20 LoC is a bit of my own invention. If the function is trivial it should be fine, but feel free to disagree :) We'll obviously revisit this guidance as time passes and we and other subsystems get more experience. Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20240830171443.3532077-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Document what was discussed multiple times on list and various
virtual / in-person conversations. guard() being okay in functions
<= 20 LoC is a bit of my own invention. If the function is trivial
it should be fine, but feel free to disagree :)

We'll obviously revisit this guidance as time passes and we and other
subsystems get more experience.

Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20240830171443.3532077-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: drop special comment style 2024-08-23T09:21:02+00:00 Johannes Berg johannes.berg@intel.com 2024-08-19T09:09:43+00:00 82b8000c28b56b014ce52a1f1581bef4af148681 As we discussed in the room at netdevconf earlier this week, drop the requirement for special comment style for netdev. For checkpatch, the general check accepts both right now, so simply drop the special request there as well. Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
As we discussed in the room at netdevconf earlier this week,
drop the requirement for special comment style for netdev.

For checkpatch, the general check accepts both right now, so
simply drop the special request there as well.

Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Documentation: embargoed-hardware-issues.rst: add a section documenting the "early access" process 2024-07-31T11:26:43+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2024-07-30T16:09:32+00:00 86fee2877f3427df5876159a182aa70d10964cdf Over the past years there have been many "misunderstandings" and "confusion" as to who is, and is not, allowed early access to the changes created by the members of the embargoed hardware issue teams working on a specific problem. The current process, while it does work, is "difficult" for many companies to understand and agree with. Because of this, there has been numerous attempts by many companies to work around the process by lies, subterfuge, and other side channels sometimes involving unsuspecting lawyers. Cut all of that out, and put the responsibility of distributing code on the silicon vendor affected, as they already have legal agreements in place that cover this type of distribution. When this distribution happens, the developers involved MUST be notified of this happening, to be kept aware of the situation at all times. The wording here has been hashed out by many different companies and lawyers involved in the process, as well as community members and everyone now agrees that the proposed change here should work better than what is currently happening. This change has been approved by a review from a large number of different open source legal members, representing the companies involved in this process. Link: https://lore.kernel.org/r/2024073035-bagel-vertigo-e0dd@gregkh Co-developed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Co-developed-by: Michael Dolan <mdolan@linuxfoundation.org> Signed-off-by: Michael Dolan <mdolan@linuxfoundation.org> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Over the past years there have been many "misunderstandings" and
"confusion" as to who is, and is not, allowed early access to the
changes created by the members of the embargoed hardware issue teams
working on a specific problem.

The current process, while it does work, is "difficult" for many
companies to understand and agree with.  Because of this, there has been
numerous attempts by many companies to work around the process by lies,
subterfuge, and other side channels sometimes involving unsuspecting
lawyers.  Cut all of that out, and put the responsibility of
distributing code on the silicon vendor affected, as they already have
legal agreements in place that cover this type of distribution.  When
this distribution happens, the developers involved MUST be notified of
this happening, to be kept aware of the situation at all times.

The wording here has been hashed out by many different companies and
lawyers involved in the process, as well as community members and
everyone now agrees that the proposed change here should work better
than what is currently happening.

This change has been approved by a review from a large number of
different open source legal members, representing the companies involved
in this process.

Link: https://lore.kernel.org/r/2024073035-bagel-vertigo-e0dd@gregkh
Co-developed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Co-developed-by: Michael Dolan <mdolan@linuxfoundation.org>
Signed-off-by: Michael Dolan <mdolan@linuxfoundation.org>
Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Documentation: embargoed-hardware-issues.rst: minor cleanups and fixes 2024-07-31T11:26:33+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2024-07-30T16:09:31+00:00 a2e4bdca2c361260609d47dff6c0e36ef2b41d4c The embargoed-hardware-issues.rst file needed a bunch of minor grammar, punctuation, and syntax cleanups based on feedback we have gotten over the past few years. The main change here is the term "silicon" being used over "hardware" to differentiate between companies that make a chip (i.e. a CPU) and those that take the chip and put it into their system. No process changes are made here at all, only clarification for the way the current process works. All of these changes have been approved by a review from a large number of different open source legal members, representing the companies involved in this process. Acked-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/2024073032-outsource-sniff-e8ea@gregkh Co-developed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Co-developed-by: Michael Dolan <mdolan@linuxfoundation.org> Signed-off-by: Michael Dolan <mdolan@linuxfoundation.org> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The embargoed-hardware-issues.rst file needed a bunch of minor grammar,
punctuation, and syntax cleanups based on feedback we have gotten over
the past few years.  The main change here is the term "silicon" being
used over "hardware" to differentiate between companies that make a chip
(i.e. a CPU) and those that take the chip and put it into their system.

No process changes are made here at all, only clarification for the way
the current process works.

All of these changes have been approved by a review from a large number
of different open source legal members, representing the companies
involved in this process.

Acked-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/2024073032-outsource-sniff-e8ea@gregkh
Co-developed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Co-developed-by: Michael Dolan <mdolan@linuxfoundation.org>
Signed-off-by: Michael Dolan <mdolan@linuxfoundation.org>
Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux 2024-07-27T20:44:54+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-07-27T20:44:54+00:00 910bfc26d16d07df5a2bfcbc63f0aa9d1397e2ef Pull Rust updates from Miguel Ojeda: "The highlight is the establishment of a minimum version for the Rust toolchain, including 'rustc' (and bundled tools) and 'bindgen'. The initial minimum will be the pinned version we currently have, i.e. we are just widening the allowed versions. That covers three stable Rust releases: 1.78.0, 1.79.0, 1.80.0 (getting released tomorrow), plus beta, plus nightly. This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Slowroll and Tumbleweed. In addition, the kernel is now being built-tested by Rust's pre-merge CI. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes. Similarly, the bindgen tool has agreed to build the kernel in their CI too. Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work. In addition, the Rust project has proposed getting the kernel into stable Rust (at least solving the main blockers) as one of its three flagship goals for 2024H2 [1]. I would like to thank Niko, Sid, Emilio et al. for their help promoting the collaboration between Rust and the kernel. Toolchain and infrastructure: - Support several Rust toolchain versions. - Support several bindgen versions. - Remove 'cargo' requirement and simplify 'rusttest', thanks to 'alloc' having been dropped last cycle. - Provide proper error reporting for the 'rust-analyzer' target. 'kernel' crate: - Add 'uaccess' module with a safe userspace pointers abstraction. - Add 'page' module with a 'struct page' abstraction. - Support more complex generics in workqueue's 'impl_has_work!' macro. 'macros' crate: - Add 'firmware' field support to the 'module!' macro. - Improve 'module!' macro documentation. Documentation: - Provide instructions on what packages should be installed to build the kernel in some popular Linux distributions. - Introduce the new kernel.org LLVM+Rust toolchains. - Explain '#[no_std]'. And a few other small bits" Link: https://rust-lang.github.io/rust-project-goals/2024h2/index.html#flagship-goals [1] * tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux: (26 commits) docs: rust: quick-start: add section on Linux distributions rust: warn about `bindgen` versions 0.66.0 and 0.66.1 rust: start supporting several `bindgen` versions rust: work around `bindgen` 0.69.0 issue rust: avoid assuming a particular `bindgen` build rust: start supporting several compiler versions rust: simplify Clippy warning flags set rust: relax most deny-level lints to warnings rust: allow `dead_code` for never constructed bindings rust: init: simplify from `map_err` to `inspect_err` rust: macros: indent list item in `paste!`'s docs rust: add abstraction for `struct page` rust: uaccess: add typed accessors for userspace pointers uaccess: always export _copy_[from|to]_user with CONFIG_RUST rust: uaccess: add userspace pointers kbuild: rust-analyzer: improve comment documentation kbuild: rust-analyzer: better error handling docs: rust: no_std is used rust: alloc: add __GFP_HIGHMEM flag rust: alloc: fix typo in docs for GFP_NOWAIT ... 
Pull Rust updates from Miguel Ojeda:
 "The highlight is the establishment of a minimum version for the Rust
  toolchain, including 'rustc' (and bundled tools) and 'bindgen'.

  The initial minimum will be the pinned version we currently have, i.e.
  we are just widening the allowed versions. That covers three stable
  Rust releases: 1.78.0, 1.79.0, 1.80.0 (getting released tomorrow),
  plus beta, plus nightly.

  This should already be enough for kernel developers in distributions
  that provide recent Rust compiler versions routinely, such as Arch
  Linux, Debian Unstable (outside the freeze period), Fedora Linux,
  Gentoo Linux (especially the testing channel), Nix (unstable) and
  openSUSE Slowroll and Tumbleweed.

  In addition, the kernel is now being built-tested by Rust's pre-merge
  CI. That is, every change that is attempting to land into the Rust
  compiler is tested against the kernel, and it is merged only if it
  passes. Similarly, the bindgen tool has agreed to build the kernel in
  their CI too.

  Thus, with the pre-merge CI in place, both projects hope to avoid
  unintentional changes to Rust that break the kernel. This means that,
  in general, apart from intentional changes on their side (that we will
  need to workaround conditionally on our side), the upcoming Rust
  compiler versions should generally work.

  In addition, the Rust project has proposed getting the kernel into
  stable Rust (at least solving the main blockers) as one of its three
  flagship goals for 2024H2 [1].

  I would like to thank Niko, Sid, Emilio et al. for their help
  promoting the collaboration between Rust and the kernel.

  Toolchain and infrastructure:

   - Support several Rust toolchain versions.

   - Support several bindgen versions.

   - Remove 'cargo' requirement and simplify 'rusttest', thanks to
     'alloc' having been dropped last cycle.

   - Provide proper error reporting for the 'rust-analyzer' target.

  'kernel' crate:

   - Add 'uaccess' module with a safe userspace pointers abstraction.

   - Add 'page' module with a 'struct page' abstraction.

   - Support more complex generics in workqueue's 'impl_has_work!'
     macro.

  'macros' crate:

   - Add 'firmware' field support to the 'module!' macro.

   - Improve 'module!' macro documentation.

  Documentation:

   - Provide instructions on what packages should be installed to build
     the kernel in some popular Linux distributions.

   - Introduce the new kernel.org LLVM+Rust toolchains.

   - Explain '#[no_std]'.

  And a few other small bits"

Link: https://rust-lang.github.io/rust-project-goals/2024h2/index.html#flagship-goals [1]

* tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux: (26 commits)
  docs: rust: quick-start: add section on Linux distributions
  rust: warn about `bindgen` versions 0.66.0 and 0.66.1
  rust: start supporting several `bindgen` versions
  rust: work around `bindgen` 0.69.0 issue
  rust: avoid assuming a particular `bindgen` build
  rust: start supporting several compiler versions
  rust: simplify Clippy warning flags set
  rust: relax most deny-level lints to warnings
  rust: allow `dead_code` for never constructed bindings
  rust: init: simplify from `map_err` to `inspect_err`
  rust: macros: indent list item in `paste!`'s docs
  rust: add abstraction for `struct page`
  rust: uaccess: add typed accessors for userspace pointers
  uaccess: always export _copy_[from|to]_user with CONFIG_RUST
  rust: uaccess: add userspace pointers
  kbuild: rust-analyzer: improve comment documentation
  kbuild: rust-analyzer: better error handling
  docs: rust: no_std is used
  rust: alloc: add __GFP_HIGHMEM flag
  rust: alloc: fix typo in docs for GFP_NOWAIT
  ...
Merge tag 'kbuild-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild 2024-07-23T21:32:21+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-07-23T21:32:21+00:00 ca83c61cb3db964061ea186654bf8e1879589de3 Pull Kbuild updates from Masahiro Yamada: - Remove tristate choice support from Kconfig - Stop using the PROVIDE() directive in the linker script - Reduce the number of links for the combination of CONFIG_KALLSYMS and CONFIG_DEBUG_INFO_BTF - Enable the warning for symbol reference to .exit.* sections by default - Fix warnings in RPM package builds - Improve scripts/make_fit.py to generate a FIT image with separate base DTB and overlays - Improve choice value calculation in Kconfig - Fix conditional prompt behavior in choice in Kconfig - Remove support for the uncommon EMAIL environment variable in Debian package builds - Remove support for the uncommon "name <email>" form for the DEBEMAIL environment variable - Raise the minimum supported GNU Make version to 4.0 - Remove stale code for the absolute kallsyms - Move header files commonly used for host programs to scripts/include/ - Introduce the pacman-pkg target to generate a pacman package used in Arch Linux - Clean up Kconfig * tag 'kbuild-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (65 commits) kbuild: doc: gcc to CC change kallsyms: change sym_entry::percpu_absolute to bool type kallsyms: unify seq and start_pos fields of struct sym_entry kallsyms: add more original symbol type/name in comment lines kallsyms: use \t instead of a tab in printf() kallsyms: avoid repeated calculation of array size for markers kbuild: add script and target to generate pacman package modpost: use generic macros for hash table implementation kbuild: move some helper headers from scripts/kconfig/ to scripts/include/ Makefile: add comment to discourage tools/* addition for kernel builds kbuild: clean up scripts/remove-stale-files kconfig: recursive checks drop file/lineno kbuild: rpm-pkg: introduce a simple changelog section for kernel.spec kallsyms: get rid of code for absolute kallsyms kbuild: Create INSTALL_PATH directory if it does not exist kbuild: Abort make on install failures kconfig: remove 'e1' and 'e2' macros from expression deduplication kconfig: remove SYMBOL_CHOICEVAL flag kconfig: add const qualifiers to several function arguments kconfig: call expr_eliminate_yn() at least once in expr_eliminate_dups() ... 
Pull Kbuild updates from Masahiro Yamada:

 - Remove tristate choice support from Kconfig

 - Stop using the PROVIDE() directive in the linker script

 - Reduce the number of links for the combination of CONFIG_KALLSYMS and
   CONFIG_DEBUG_INFO_BTF

 - Enable the warning for symbol reference to .exit.* sections by
   default

 - Fix warnings in RPM package builds

 - Improve scripts/make_fit.py to generate a FIT image with separate
   base DTB and overlays

 - Improve choice value calculation in Kconfig

 - Fix conditional prompt behavior in choice in Kconfig

 - Remove support for the uncommon EMAIL environment variable in Debian
   package builds

 - Remove support for the uncommon "name <email>" form for the DEBEMAIL
   environment variable

 - Raise the minimum supported GNU Make version to 4.0

 - Remove stale code for the absolute kallsyms

 - Move header files commonly used for host programs to scripts/include/

 - Introduce the pacman-pkg target to generate a pacman package used in
   Arch Linux

 - Clean up Kconfig

* tag 'kbuild-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (65 commits)
  kbuild: doc: gcc to CC change
  kallsyms: change sym_entry::percpu_absolute to bool type
  kallsyms: unify seq and start_pos fields of struct sym_entry
  kallsyms: add more original symbol type/name in comment lines
  kallsyms: use \t instead of a tab in printf()
  kallsyms: avoid repeated calculation of array size for markers
  kbuild: add script and target to generate pacman package
  modpost: use generic macros for hash table implementation
  kbuild: move some helper headers from scripts/kconfig/ to scripts/include/
  Makefile: add comment to discourage tools/* addition for kernel builds
  kbuild: clean up scripts/remove-stale-files
  kconfig: recursive checks drop file/lineno
  kbuild: rpm-pkg: introduce a simple changelog section for kernel.spec
  kallsyms: get rid of code for absolute kallsyms
  kbuild: Create INSTALL_PATH directory if it does not exist
  kbuild: Abort make on install failures
  kconfig: remove 'e1' and 'e2' macros from expression deduplication
  kconfig: remove SYMBOL_CHOICEVAL flag
  kconfig: add const qualifiers to several function arguments
  kconfig: call expr_eliminate_yn() at least once in expr_eliminate_dups()
  ...
Merge tag 'docs-6.11' of git://git.lwn.net/linux 2024-07-18T22:54:16+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-07-18T22:54:16+00:00 cf05e93af423b225fb3e3237e7d46493c7909f2b Pull documentation updates from Jonathan Corbet: "Nothing hugely exciting happening in the documentation tree this time around, mostly more of the usual: - More Spanish, Italian, and Chinese translations - A new script, scripts/checktransupdate.py, can be used to see which commits have touched an (English) document since a given translation was last updated. - A couple of "best practices" suggestions (on Link: tags and off-list discussions) that were not entirely at consensus level, but I concluded they were close enough to accept. - Some nice cleanups removing documentation for kernel parameters that have not been recognized for ... a long time. ...along with the usual updates, typo fixes, and such" * tag 'docs-6.11' of git://git.lwn.net/linux: (57 commits) Documentation: Document user_events ioctl code docs/pinctrl: fix typo in mapping example docs: maintainer: discourage taking conversations off-list docs: driver-model: platform: update the definition of platform_driver docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst writing_musb_glue_layer.rst: Fix broken URL zh_CN/admin-guide: one typo fix docs/zh_CN/virt: Update the translation of guest-halt-polling.rst Documentation: add reference from dynamic debug to loglevel kernel params Documentation: best practices for using Link trailers Documentation: fix links to mailing list services Documentation: exception-tables.rst: Fix the wrong steps referenced docs/zh_CN: add process/researcher-guidelines Chinese translation Documentation/tools/rv: fix document header docs/sp_SP: Add translation of process/maintainer-kvm-x86.rst docs/admin-guide/mm: correct typo 'quired' to 'queried' Add libps2 to the input section of driver-api Docs/mm/index: move allocation profiling document to unsorted documents chapter Docs/mm/index: rename 'Legacy Documentation' to 'Unsorted Documentation' Docs/mm/index: Remove 'Memory Management Guide' chapter marker ... 
Pull documentation updates from Jonathan Corbet:
 "Nothing hugely exciting happening in the documentation tree this time
  around, mostly more of the usual:

   - More Spanish, Italian, and Chinese translations

   - A new script, scripts/checktransupdate.py, can be used to see which
     commits have touched an (English) document since a given
     translation was last updated.

   - A couple of "best practices" suggestions (on Link: tags and
     off-list discussions) that were not entirely at consensus level,
     but I concluded they were close enough to accept.

   - Some nice cleanups removing documentation for kernel parameters
     that have not been recognized for ... a long time.

  ...along with the usual updates, typo fixes, and such"

* tag 'docs-6.11' of git://git.lwn.net/linux: (57 commits)
  Documentation: Document user_events ioctl code
  docs/pinctrl: fix typo in mapping example
  docs: maintainer: discourage taking conversations off-list
  docs: driver-model: platform: update the definition of platform_driver
  docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst
  writing_musb_glue_layer.rst: Fix broken URL
  zh_CN/admin-guide: one typo fix
  docs/zh_CN/virt: Update the translation of guest-halt-polling.rst
  Documentation: add reference from dynamic debug to loglevel kernel params
  Documentation: best practices for using Link trailers
  Documentation: fix links to mailing list services
  Documentation: exception-tables.rst: Fix the wrong steps referenced
  docs/zh_CN: add process/researcher-guidelines Chinese translation
  Documentation/tools/rv: fix document header
  docs/sp_SP: Add translation of process/maintainer-kvm-x86.rst
  docs/admin-guide/mm: correct typo 'quired' to 'queried'
  Add libps2 to the input section of driver-api
  Docs/mm/index: move allocation profiling document to unsorted documents chapter
  Docs/mm/index: rename 'Legacy Documentation' to 'Unsorted Documentation'
  Docs/mm/index: Remove 'Memory Management Guide' chapter marker
  ...
kbuild: raise the minimum GNU Make requirement to 4.0 2024-07-16T07:07:14+00:00 Masahiro Yamada masahiroy@kernel.org 2024-07-04T13:47:55+00:00 5f99665ee8f4335f334a5292b6d5b41a577fc2c0 RHEL/CentOS 7, popular distributions that install GNU Make 3.82, reached EOM/EOL on June 30, 2024. While you may get extended support, it is a good time to raise the minimum GNU Make version. The new requirement, GNU Make 4.0, was released in October, 2013. I did not touch the Makefiles under tools/ because I do not know the requirements for building tools. I do not find any GNU Make version checks under tools/. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> 
RHEL/CentOS 7, popular distributions that install GNU Make 3.82, reached
EOM/EOL on June 30, 2024. While you may get extended support, it is a
good time to raise the minimum GNU Make version.

The new requirement, GNU Make 4.0, was released in October, 2013.

I did not touch the Makefiles under tools/ because I do not know the
requirements for building tools. I do not find any GNU Make version
checks under tools/.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
docs: rust: quick-start: add section on Linux distributions 2024-07-10T08:29:55+00:00 Miguel Ojeda ojeda@kernel.org 2024-07-09T16:06:08+00:00 b1263411112305acf2af728728591465becb45b0 Now that we are starting to support several Rust compiler and `bindgen` versions, there is a good chance some Linux distributions work out of the box. Thus, provide some instructions on how to set the toolchain up for a few major Linux distributions. This simplifies the setup users need to build the kernel. In addition, add an introduction to the document so that it is easier to understand its structure and move the LLVM+Rust kernel.org toolchains paragraph there (removing "depending on the Linux version"). We may want to reorganize the document or split it in the future, but I wanted to focus this commit on the new information added about each particular distribution. Finally, remove the `rustup`'s components mention in `changes.rst` since users do not need it if they install the toolchain via the distributions (and anyway it was too detailed for that main document). Cc: Jan Alexander Steffens <heftig@archlinux.org> Cc: Johannes Löthberg <johannes@kyriasis.com> Cc: Fabian Grünbichler <debian@fabian.gruenbichler.email> Cc: Josh Stone <jistone@redhat.com> Cc: Randy Barlow <randy@electronsweatshop.com> Cc: Anna (navi) Figueiredo Gomes <navi@vlhl.dev> Cc: Matoro Mahri <matoro_gentoo@matoro.tk> Cc: Ryan Scheel <ryan.havvy@gmail.com> Cc: figsoda <figsoda@pm.me> Cc: Jörg Thalheim <joerg@thalheim.io> Cc: Theodore Ni <43ngvg@masqt.com> Cc: Winter <nixos@winter.cafe> Cc: William Brown <wbrown@suse.de> Cc: Xiaoguang Wang <xiaoguang.wang@suse.com> Cc: Andrea Righi <andrea.righi@canonical.com> Cc: Zixing Liu <zixing.liu@canonical.com> Cc: Nathan Chancellor <nathan@kernel.org> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-14-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> 
Now that we are starting to support several Rust compiler and `bindgen`
versions, there is a good chance some Linux distributions work out of
the box.

Thus, provide some instructions on how to set the toolchain up for a
few major Linux distributions. This simplifies the setup users need to
build the kernel.

In addition, add an introduction to the document so that it is easier
to understand its structure and move the LLVM+Rust kernel.org toolchains
paragraph there (removing "depending on the Linux version"). We may want
to reorganize the document or split it in the future, but I wanted to
focus this commit on the new information added about each particular
distribution.

Finally, remove the `rustup`'s components mention in `changes.rst` since
users do not need it if they install the toolchain via the distributions
(and anyway it was too detailed for that main document).

Cc: Jan Alexander Steffens <heftig@archlinux.org>
Cc: Johannes Löthberg <johannes@kyriasis.com>
Cc: Fabian Grünbichler <debian@fabian.gruenbichler.email>
Cc: Josh Stone <jistone@redhat.com>
Cc: Randy Barlow <randy@electronsweatshop.com>
Cc: Anna (navi) Figueiredo Gomes <navi@vlhl.dev>
Cc: Matoro Mahri <matoro_gentoo@matoro.tk>
Cc: Ryan Scheel <ryan.havvy@gmail.com>
Cc: figsoda <figsoda@pm.me>
Cc: Jörg Thalheim <joerg@thalheim.io>
Cc: Theodore Ni <43ngvg@masqt.com>
Cc: Winter <nixos@winter.cafe>
Cc: William Brown <wbrown@suse.de>
Cc: Xiaoguang Wang <xiaoguang.wang@suse.com>
Cc: Andrea Righi <andrea.righi@canonical.com>
Cc: Zixing Liu <zixing.liu@canonical.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-14-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
rust: start supporting several compiler versions 2024-07-10T08:28:52+00:00 Miguel Ojeda ojeda@kernel.org 2024-07-09T16:06:01+00:00 63b27f4a0074bc6ef987a44ee9ad8bf960b568c2 It is time to start supporting several Rust compiler versions and thus establish a minimum Rust version. We may still want to upgrade the minimum sometimes in the beginning since there may be important features coming into the language that improve how we write code (e.g. field projections), which may or may not make sense to support conditionally. We will start with a window of two stable releases, and widen it over time. Thus this patch does not move the current minimum (1.78.0), but instead adds support for the recently released 1.79.0. This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Tumbleweed. See the documentation patch about it later in this series. In addition, Rust for Linux is now being built-tested in Rust's pre-merge CI [1]. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes -- thanks to the Rust project for that! Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work. For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches work as well. Of course, the Rust for Linux CI job in the Rust toolchain may still need to be temporarily disabled for different reasons, but the intention is to help bring Rust for Linux into stable Rust. Link: https://github.com/rust-lang/rust/pull/125209 [1] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-7-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> 
It is time to start supporting several Rust compiler versions and thus
establish a minimum Rust version.

We may still want to upgrade the minimum sometimes in the beginning since
there may be important features coming into the language that improve
how we write code (e.g. field projections), which may or may not make
sense to support conditionally.

We will start with a window of two stable releases, and widen it over
time. Thus this patch does not move the current minimum (1.78.0), but
instead adds support for the recently released 1.79.0.

This should already be enough for kernel developers in distributions that
provide recent Rust compiler versions routinely, such as Arch Linux,
Debian Unstable (outside the freeze period), Fedora Linux, Gentoo
Linux (especially the testing channel), Nix (unstable) and openSUSE
Tumbleweed. See the documentation patch about it later in this series.

In addition, Rust for Linux is now being built-tested in Rust's pre-merge
CI [1]. That is, every change that is attempting to land into the Rust
compiler is tested against the kernel, and it is merged only if it passes
-- thanks to the Rust project for that!

Thus, with the pre-merge CI in place, both projects hope to avoid
unintentional changes to Rust that break the kernel. This means that,
in general, apart from intentional changes on their side (that we will
need to workaround conditionally on our side), the upcoming Rust compiler
versions should generally work.

For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches
work as well.

Of course, the Rust for Linux CI job in the Rust toolchain may still need
to be temporarily disabled for different reasons, but the intention is
to help bring Rust for Linux into stable Rust.

Link: https://github.com/rust-lang/rust/pull/125209 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-7-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>