History log of /linux/Documentation/process/index.rst (Results 1 – 25 of 32)
Revision Date Author Comments
# 5928d411 17-Feb-2024 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation: Document the Linux Kernel CVE process

The Linux kernel project now has the ability to assign CVEs to fixed
issues, so document the process and how individual developers can get a
CVE

Documentation: Document the Linux Kernel CVE process

The Linux kernel project now has the ability to assign CVEs to fixed
issues, so document the process and how individual developers can get a
CVE if one is not automatically assigned for their fixes.

Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/2024021731-essence-sadness-28fd@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 53827745 10-Nov-2023 Jonathan Corbet <corbet@lwn.net>

A reworked process/index.rst

The process book is arguably the most important documentation we have; the
top three trafficked pages on docs.kernel.org are found here. Make a
beginning effort to impo

A reworked process/index.rst

The process book is arguably the most important documentation we have; the
top three trafficked pages on docs.kernel.org are found here. Make a
beginning effort to impose a more useful organization on this page to ease
developers into the community.

Acked-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# f1477dbf 24-Aug-2023 Vegard Nossum <vegard.nossum@oracle.com>

docs: add backporting and conflict resolution document

This is a new document based on my 2022 blog post:

https://blogs.oracle.com/linux/post/backporting-patches-using-git

Although this is aimed

docs: add backporting and conflict resolution document

This is a new document based on my 2022 blog post:

https://blogs.oracle.com/linux/post/backporting-patches-using-git

Although this is aimed at stable contributors and distro maintainers,
it does also contain useful tips and tricks for anybody who needs to
resolve merge conflicts.

By adding this to the kernel as documentation we can more easily point
to it e.g. from stable emails about failed backports, as well as allow
the community to modify it over time if necessary.

I've added this under process/ since it also has
process/applying-patches.rst. Another interesting document is
maintainer/rebasing-and-merging.rst which maybe should eventually refer
to this one, but I'm leaving that as a future cleanup.

Thanks to Harshit Mogalapalli for helping with the original blog post
as well as this updated document and Bagas Sanjaya for providing
thoughtful feedback.

v2: fixed heading style, link style, placeholder style, other comments

Link: https://lore.kernel.org/linux-doc/20230303162553.17212-1-vegard.nossum@oracle.com/
Cc: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Rule: stable@vger.kernel.org'or'commit
Link: https://lore.kernel.org/stable/20230824092325.1464227-1-vegard.nossum%40oracle.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20230824092325.1464227-1-vegard.nossum@oracle.com

show more ...


# ed843ae9 30-Sep-2023 Costa Shulyupin <costa.shul@redhat.com>

docs: move riscv under arch

and fix all in-tree references.

Architecture-specific documentation is being moved into Documentation/arch/
as a way of cleaning up the top-level documentation directory

docs: move riscv under arch

and fix all in-tree references.

Architecture-specific documentation is being moved into Documentation/arch/
as a way of cleaning up the top-level documentation directory and making
the docs hierarchy more closely match the source hierarchy.

Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20230930185354.3034118-1-costa.shul@redhat.com

show more ...


# 10a29eb6 08-Mar-2023 Theodore Ts'o <tytso@mit.edu>

Documentation/process: Add Linux Kernel Contribution Maturity Model

As a follow-up to a discussion at the 2021 Maintainer's Summit on the
topic of maintainer recruitment and retention, the TAB took

Documentation/process: Add Linux Kernel Contribution Maturity Model

As a follow-up to a discussion at the 2021 Maintainer's Summit on the
topic of maintainer recruitment and retention, the TAB took on the
task of creating a document which to help companies and other
organizations to grow in their ability to engage with the Linux Kernel
development community, using the Maturity Model[2] framework.

The goal is to encourage, in a management-friendly way, companies to
allow their engineers to contribute with the upstream Linux Kernel
development community, so we can grow the "talent pipeline" for
contributors to become respected leaders, and eventually kernel
maintainers.

[1] https://lwn.net/Articles/870581/
[2] https://en.wikipedia.org/wiki/Maturity_model

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230308190403.2157046-1-tytso@mit.edu
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 44ac5aba 05-Mar-2023 Vegard Nossum <vegard.nossum@oracle.com>

Documentation/security-bugs: move from admin-guide/ to process/

Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
to move this document under process/.

Create a new section for

Documentation/security-bugs: move from admin-guide/ to process/

Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire
to move this document under process/.

Create a new section for security issues in the index and group it with
embargoed-hardware-issues.

I'm doing this at the start of the series to make all the subsequent
changes show up in 'git blame'.

Existing references were updated using:

git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g'
git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g'
git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g'

Notably, the page is not moved in the translations (due to my lack of
knowledge of these languages), but the translations have been updated
to point to the new location of the original document where these
references exist.

Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/
Suggested-by: Jiri Kosina <jikos@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Cc: Hu Haowen <src.res@email.cn>
Cc: Federico Vaga <federico.vaga@vaga.pv.it>
Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jeimi Lee <jamee.lee@samsung.com>
Cc: Carlos Bilbao <carlos.bilbao@amd.com>
Cc: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-by: Carlos Bilbao <carlos.bilbao@amd.com>
Reviewed-by: Yanteng Si <siyanteng@loongson.cn>
Reviewed-by: Akira Yokosawa <akiyks@gmail.com>
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Link: https://lore.kernel.org/r/20230305220010.20895-2-vegard.nossum@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 9d0f5cd1 27-Sep-2022 Jonathan Corbet <corbet@lwn.net>

docs: promote the title of process/index.rst

...otherwise Sphinx won't cooperate when trying to list it explicitly in
the top-level index.rst file

Reviewed-by: David Vernet <void@manifault.com>
Ack

docs: promote the title of process/index.rst

...otherwise Sphinx won't cooperate when trying to list it explicitly in
the top-level index.rst file

Reviewed-by: David Vernet <void@manifault.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220927160559.97154-2-corbet@lwn.net
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 9db370de 04-Jul-2022 Lukas Bulwahn <lukas.bulwahn@gmail.com>

docs: process: remove outdated submitting-drivers.rst

Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst")
in October 2016 already warns "This (...) should maybe just be deleted,
bu

docs: process: remove outdated submitting-drivers.rst

Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst")
in October 2016 already warns "This (...) should maybe just be deleted,
but I'm not quite ready to do that yet".

Maybe, six years ago, we were not ready but let us remove old content
for the better now and structure and maintain less content in the kernel
documentation with a better result.

Drop this already outdated document and adjust all textual references.

Here is an argument why deleting the content will not remove any useful
information to the existing kernel documentation, individually broken down
for each section.

Section "Allocating Device Numbers" refers to https://www.lanana.org/, and
then refers to Documentation/admin-guide/devices.rst.

However, the devices.rst clearly states:

"The version of this document at lanana.org is no longer maintained."

Everything needed for submitting drivers is already stated in devices.rst
and the reference to https://www.lanana.org/ is outdated, and should be
just deleted.

Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before
the new release version scheme; the mentioned developers are still around,
but actually not the first developers to contact anymore.

Section "What Criteria Determine Acceptance" has a few bullet points:

Licensing and Copyright is well-covered in process/kernel-license.rst.

Interfaces, Code, Portability, Clarity state some obvious things about
ensuring kernel code quality.

Control suggests to add a MAINTAINERS entry, which is already mentioned in
6.Followthrough.rst: "... added yourself to the MAINTAINERS file..."

PM support states a bit about implementing and testing power management of
a driver, it remains an open question where to place that in the process
documents. Driver developers interested in power management will find the
corresponding part on power management in the kernel documentation anyway.

In section "What Criteria Do Not Determine Acceptance", the points Vendor
and Author states something basic consequence of the kernel being an
open-source community software development. Probably no need to mention it
nowadays.

Section "Resources" lists resources that are also mentioned elsewhere more
central.

- Linux kernel tree and mailing list is mentioned in many places.
- https://lwn.net/Kernel/LDD3/ is mentioned in
Documentation/process/kernel-docs.rst.

- https://lwn.net/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst

- https://kernelnewbies.org/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst

- http://www.linux-usb.org/ is mentioned in
Documentation/driver-api/usb/usb.rst

- https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
is mentioned in Documentation/process/kernel-docs.rst

- https://kernelnewbies.org/KernelJanitors is mentioned in
Documentation/process/howto.rst

- https://git-scm.com/ is mentioned in
- Documentation/process/2.Process.rst
- Documentation/process/7.AdvancedTopics.rst
- Documentation/process/howto.rst

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# f09f6f9b 04-Mar-2022 Kees Cook <keescook@chromium.org>

Documentation/process: Add Researcher Guidelines

As a follow-up to the UMN incident[1], the TAB took the responsibility
to document Researcher Guidelines so there would be a common place to
point fo

Documentation/process: Add Researcher Guidelines

As a follow-up to the UMN incident[1], the TAB took the responsibility
to document Researcher Guidelines so there would be a common place to
point for describing our expectations as a developer community.

Document best practices researchers should follow to participate
successfully with the Linux developer community.

[1] https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/

Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Co-developed-by: Jonathan Corbet <corbet@lwn.net>
Co-developed-by: Stefano Zacchiroli <zack@upsilon.cc>
Signed-off-by: Stefano Zacchiroli <zack@upsilon.cc>
Co-developed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Steve Rostedt <rostedt@goodmis.org>
Acked-by: Laura Abbott <labbott@kernel.org>
Reviewed-by: Julia Lawall <julia.lawall@inria.fr>
Reviewed-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220304181418.1692016-1-keescook@chromium.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 1ecf393f 16-Feb-2022 Thorsten Leemhuis <linux@leemhuis.info>

docs: add two documents about regression handling

Create two documents explaining various aspects around regression
handling and tracking; one is aimed at users, the other targets
developers.

The t

docs: add two documents about regression handling

Create two documents explaining various aspects around regression
handling and tracking; one is aimed at users, the other targets
developers.

The texts among others describes the first rule of Linux kernel
development and what it means in practice. They also explain what a
regression actually is and how to report one properly.

Both texts additionally provide a brief introduction to the bot the
kernel's regression tracker uses to facilitate the work, but mention the
use is optional.

To sum things up, provide a few quotes from Linus in the document for
developers to show how serious we take regressions.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://lore.kernel.org/r/34e56d3588f22d7e0b4d635ef9c9c3b33ca4ac04.1644994117.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 604370e1 13-Sep-2021 Thomas Gleixner <tglx@linutronix.de>

Documentation/process: Add maintainer handbooks section

General rules for patch submission, coding style and related details are
available, but most subsystems have their subsystem-specific extra ru

Documentation/process: Add maintainer handbooks section

General rules for patch submission, coding style and related details are
available, but most subsystems have their subsystem-specific extra rules
which differ or go beyond the common rules.

Mark suggested to add a subsystem/maintainer handbook section, where
subsystem maintainers can explain their specific quirks.

Add the section and link to it from the submitting-patches document.

[ bp: Add a SPDX identifier. ]

Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20181107171149.074948887@linutronix.de
Link: https://lore.kernel.org/r/20210913153942.15251-2-bp@alien8.de
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# b6667585 18-Jul-2020 Daniel W. S. Almeida <dwlsalmeida@gmail.com>

docs: process/index.rst: Fix reference to nonexistent document

Fix the following warning:

WARNING: toctree contains reference to nonexistent document
'process/unaligned-memory-access'

The path to

docs: process/index.rst: Fix reference to nonexistent document

Fix the following warning:

WARNING: toctree contains reference to nonexistent document
'process/unaligned-memory-access'

The path to the document was wrong.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Link: https://lore.kernel.org/r/20200718165107.625847-5-dwlsalmeida@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 997c798e 15-May-2020 Stephen Kitt <steve@sk2.org>

docs: sysctl/kernel: document unaligned controls

This documents ignore-unaligned-usertrap, unaligned-dump-stack, and
unaligned-trap, based on arch/arc/kernel/unaligned.c,
arch/ia64/kernel/unaligned.

docs: sysctl/kernel: document unaligned controls

This documents ignore-unaligned-usertrap, unaligned-dump-stack, and
unaligned-trap, based on arch/arc/kernel/unaligned.c,
arch/ia64/kernel/unaligned.c, and arch/parisc/kernel/unaligned.c.

While we're at it, integrate unaligned-memory-access.txt into the docs
tree.

Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20200515212443.5012-1-steve@sk2.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 0e194d9d 23-Nov-2019 Paul Walmsley <paul.walmsley@sifive.com>

Documentation: riscv: add patch acceptance guidelines

Formalize, in kernel documentation, the patch acceptance policy for
arch/riscv. In summary, it states that as maintainers, we plan to
only acce

Documentation: riscv: add patch acceptance guidelines

Formalize, in kernel documentation, the patch acceptance policy for
arch/riscv. In summary, it states that as maintainers, we plan to
only accept patches for new modules or extensions that have been
frozen or ratified by the RISC-V Foundation.

We've been following these guidelines for the past few months. In the
meantime, we've received quite a bit of feedback that it would be
helpful to have these guidelines formally documented.

Based on a suggestion from Matthew Wilcox, we also add a link to this
file to Documentation/process/index.rst, to make this document easier
to find. The format of this document has also been changed to align
to the format outlined in the maintainer entry profiles, in accordance
with comments from Jon Corbet and Dan Williams.

Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Krste Asanovic <krste@berkeley.edu>
Cc: Andrew Waterman <waterman@eecs.berkeley.edu>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>

show more ...


# 5ecd0a06 03-Oct-2019 Jonathan Corbet <corbet@lwn.net>

docs: move botching-up-ioctls.rst to the process guide

This is overall information for kernel developers, and not part of the
user-space API.

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jona

docs: move botching-up-ioctls.rst to the process guide

This is overall information for kernel developers, and not part of the
user-space API.

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# aa204855 01-Oct-2019 Kees Cook <keescook@chromium.org>

doc-rst: Programmatically render MAINTAINERS into ReST

In order to have the MAINTAINERS file visible in the rendered ReST
output, this makes some small changes to the existing MAINTAINERS file
to al

doc-rst: Programmatically render MAINTAINERS into ReST

In order to have the MAINTAINERS file visible in the rendered ReST
output, this makes some small changes to the existing MAINTAINERS file
to allow for better machine processing, and adds a new Sphinx directive
"maintainers-include" to perform the rendering.

Features include:
- Per-subsystem reference links: subsystem maintainer entries can be
trivially linked to both internally and external. For example:
https://www.kernel.org/doc/html/latest/process/maintainers.html#secure-computing

- Internally referenced .rst files are linked so they can be followed
when browsing the resulting rendering. This allows, for example, the
future addition of maintainer profiles to be automatically linked.

- Field name expansion: instead of the short fields (e.g. "M", "F",
"K"), use the indicated inline "full names" for the fields (which are
marked with "*"s in MAINTAINERS) so that a rendered subsystem entry
is more human readable. Email lists are additionally comma-separated.
For example:

SECURE COMPUTING
Mail: Kees Cook <keescook@chromium.org>
Reviewer: Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>
SCM: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp
Status: Supported
Files: kernel/seccomp.c include/uapi/linux/seccomp.h
include/linux/seccomp.h tools/testing/selftests/seccomp/*
tools/testing/selftests/kselftest_harness.h
userspace-api/seccomp_filter
Content regex: \bsecure_computing \bTIF_SECCOMP\b

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# ddaedbbe 15-Aug-2019 Thomas Gleixner <tglx@linutronix.de>

Documentation/process: Embargoed hardware security issues

To address the requirements of embargoed hardware issues, like Meltdown,
Spectre, L1TF etc. it is necessary to define and document a process

Documentation/process: Embargoed hardware security issues

To address the requirements of embargoed hardware issues, like Meltdown,
Spectre, L1TF etc. it is necessary to define and document a process for
handling embargoed hardware security issues.

Following the discussion at the maintainer summit 2018 in Edinburgh
(https://lwn.net/Articles/769417/) the volunteered people have worked
out a process and a Memorandum of Understanding. The latter addresses
the fact that the Linux kernel community cannot sign NDAs for various
reasons.

The initial contact point for hardware security issues is different from
the regular kernel security contact to provide a known and neutral
interface for hardware vendors and researchers. The initial primary
contact team is proposed to be staffed by Linux Foundation Fellows, who
are not associated to a vendor or a distribution and are well connected
in the industry as a whole.

The process is designed with the experience of the past incidents in
mind and tries to address the remaining gaps, so future (hopefully rare)
incidents can be handled more efficiently. It won't remove the fact,
that most of this has to be done behind closed doors, but it is set up
to avoid big bureaucratic hurdles for individual developers.

The process is solely for handling hardware security issues and cannot
be used for regular kernel (software only) security bugs.

This memo can help with hardware companies who, and I quote, "[my
manager] doesn't want to bet his job on the list keeping things secret."
This despite numerous leaks directly from that company over the years,
and none ever so far from the kernel security team. Cognitive
dissidence seems to be a requirement to be a good manager.

To accelerate the adoption of this process, we introduce the concept of
ambassadors in participating companies. The ambassadors are there to
guide people to comply with the process, but are not automatically
involved in the disclosure of a particular incident.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Acked-by: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/r/20190815212505.GC12041@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 79dbeed3 14-Oct-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted

The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules fo

Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted

The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will interpret it. We also do not expect this interpretation
to be static over time, and will adjust it as needed.

This document was created with the input and feedback of the TAB as well
as many current kernel maintainers.

Co-Developed-by: Thomas Gleixner <tglx@linutronix.de>
Co-Developed-by: Olof Johansson <olof@lixom.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Mishi Choudhary <mishi@linux.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 84253c8b 17-Oct-2018 Kees Cook <keescook@chromium.org>

docs: Introduce deprecated APIs list

As discussed in the "API replacement/deprecation" thread[1], this makes
an effort to document what things shouldn't get (re)added to the kernel,
by introducing D

docs: Introduce deprecated APIs list

As discussed in the "API replacement/deprecation" thread[1], this makes
an effort to document what things shouldn't get (re)added to the kernel,
by introducing Documentation/process/deprecated.rst.

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2018-September/005282.html

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 303d22c5 03-Sep-2018 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

Compiler Attributes: add Doc/process/programming-language.rst

Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # on top of v4.19-rc5, clang 7
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Re

Compiler Attributes: add Doc/process/programming-language.rst

Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # on top of v4.19-rc5, clang 7
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

show more ...


# 8a104f8b 15-Sep-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code of Conduct: Let's revamp it.

The Code of Conflict is not achieving its implicit goal of fostering
civility and the spirit of 'be excellent to each other'. Explicit
guidelines have demonstrated

Code of Conduct: Let's revamp it.

The Code of Conflict is not achieving its implicit goal of fostering
civility and the spirit of 'be excellent to each other'. Explicit
guidelines have demonstrated success in other projects and other areas
of the kernel.

Here is a Code of Conduct statement for the wider kernel. It is based
on the Contributor Covenant as described at www.contributor-covenant.org

From this point forward, we should abide by these rules in order to help
make the kernel community a welcoming environment to participate in.

Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Olof Johansson <olof@lxom.net>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...


# 9799445a 14-Aug-2018 Markus Heiser <markus.heiser@darmarit.de>

docs: tidy up TOCs and refs to license-rules.rst

The documentation and TOCs are organized in a manner of a tree. Adding a TOC to
the root, which refers to a file which is located in a subfolder form

docs: tidy up TOCs and refs to license-rules.rst

The documentation and TOCs are organized in a manner of a tree. Adding a TOC to
the root, which refers to a file which is located in a subfolder forms a
grid. Those TOCs are a bit confusing and thats why we get additional error
messages while building partial documentation::

$ make SPHINXDIRS=process htmldocs
...
checking consistency... Documentation/process/license-rules.rst: \
WARNING: document isn't included in any toctree

To fix it, the *root-license-TOC* is replaced by a reference and the
'license-roles.txt' is added to the Documentation/process/index.rst TOC.

BTW: there was an old licences remark in Documentation/process/howto.rst which
is also updated, mentioning SPDX and pointing to the license-rules.rst

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 2d93404f 07-May-2018 Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

docs: */index.rst: Add newer documents to their respective index.rst

A number of new docs were added, but they're currently not on
the index.rst from the session they're supposed to be, causing
Sphi

docs: */index.rst: Add newer documents to their respective index.rst

A number of new docs were added, but they're currently not on
the index.rst from the session they're supposed to be, causing
Sphinx warnings.

Add them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# b72dde38 01-Feb-2018 Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Documentation/process: kernel maintainer PGP guide

This guide is an adapted version of the more general "Protecting Code
Integrity" guide written and maintained by The Linux Foundation IT for
use wi

Documentation/process: kernel maintainer PGP guide

This guide is an adapted version of the more general "Protecting Code
Integrity" guide written and maintained by The Linux Foundation IT for
use with open-source projects. It provides the oft-lacking guidance on
the following topics:

- how to properly protect one's PGP keys to minimize the risks of them
being stolen and used maliciously to impersonate a kernel developer
- how to configure Git to properly use GnuPG
- when and how to use PGP with Git
- how to verify fellow Linux Kernel developer identities

I believe this document should live with the rest of the documentation
describing proper processes one should follow when participating in
kernel development. Placing it in a wiki on some place like kernel.org
would be insufficient for a number of reasons -- primarily, because only
a relatively small subset of maintainers have accounts on kernel.org,
but also because even those who do rarely remember that such wiki
exists. Keeping it with the rest of in-kernel docs should hopefully give
it more visibility, but also help keep it up-to-date as tools and
processes evolve.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...


# 9ed95129 04-Oct-2017 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation: Add a file explaining the Linux kernel license enforcement policy

This adds a short document describing the views of how the Linux kernel
community feels about enforcing the license o

Documentation: Add a file explaining the Linux kernel license enforcement policy

This adds a short document describing the views of how the Linux kernel
community feels about enforcing the license of the kernel.

Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Alex Elder (Linaro) <elder@linaro.org>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Andy Gross <andy.gross@linaro.org>
Acked-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Anna Schumaker <schumaker.anna@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Bart Van Assche <bart.vanassche@wdc.com>
Acked-by: Bhumika Goyal <bhumirks@gmail.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Chuck Lever <chuck.lever@oracle.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Darrick J. Wong (Oracle) <darrick.wong@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Acked-by: David Kershner <david.kershner@unisys.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Acked-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Hannes Reinecke <hare@suse.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Ivan Safonov <insafonov@gmail.com>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: Jan Kara (SUSE) <jack@suse.cz>
Acked-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Joe Perches <joe@perches.com>
Acked-by: Joerg Roedel (SUSE) <jroedel@suse.de>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: Khalid Aziz <khalid@gonehiking.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Laura Abbott <laura@labbott.name>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Leon Romanovsky <leon@kernel.org>
Acked-by: Linus Walleij (Linaro) <linus.walleij@linaro.org>
Acked-by: Lv Zheng <zetalog@gmail.com>
Acked-by: Martin K. Petersen (Oracle) <martin.petersen@oracle.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Mike Marshall <hubcap@omnibond.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Paul Burton <paul.burton@mips.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Sebastian Reichel (Collabora) <sre@kernel.org>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: Sven Eckelmann <sven@narfation.org>
Acked-by: Takashi Iwai (SUSE) <tiwai@suse.de>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Tony Luck <tony.luck@gmail.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


12