#
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 ...
|