2016-09-21 14:40:21 +03:00
.. raw :: latex
\renewcommand\thesection*
\renewcommand\thesubsection*
2017-03-21 18:52:28 +03:00
.. _process_index:
2016-09-21 14:40:21 +03:00
2022-09-27 19:05:53 +03:00
=============================================
2016-10-27 01:34:09 +03:00
Working with the kernel development community
=============================================
2016-09-19 14:07:38 +03:00
2016-10-27 01:34:09 +03:00
So you want to be a Linux kernel developer? Welcome! While there is a lot
to be learned about the kernel in a technical sense, it is also important
to learn about how our community works. Reading these documents will make
it much easier for you to get your changes merged with a minimum of
trouble.
Below are the essential guides that every developer should read.
2016-09-19 14:07:38 +03:00
.. toctree ::
2016-10-27 01:41:05 +03:00
:maxdepth: 1
2016-09-19 14:07:38 +03:00
2018-08-14 14:43:12 +03:00
license-rules
2016-09-21 14:40:21 +03:00
howto
2018-09-15 21:26:44 +03:00
code-of-conduct
2018-10-14 17:16:47 +03:00
code-of-conduct-interpretation
2016-10-27 01:34:09 +03:00
development-process
2016-09-21 14:40:21 +03:00
submitting-patches
2022-02-16 09:51:33 +03:00
handling-regressions
2018-09-03 19:32:11 +03:00
programming-language
2016-10-27 01:34:09 +03:00
coding-style
2021-09-13 18:39:41 +03:00
maintainer-handbooks
2018-02-01 17:42:33 +03:00
maintainer-pgp-guide
2016-10-27 01:34:09 +03:00
email-clients
2017-10-04 17:17:55 +03:00
kernel-enforcement-statement
2017-10-06 12:10:38 +03:00
kernel-driver-statement
2016-10-27 01:34:09 +03:00
2020-07-18 19:50:59 +03:00
Other guides to the community that are of interest to most developers are:
2016-10-27 01:34:09 +03:00
.. toctree ::
2016-10-27 01:41:05 +03:00
:maxdepth: 1
2016-10-27 01:34:09 +03:00
changes
2016-09-21 14:40:21 +03:00
stable-api-nonsense
management-style
stable-kernel-rules
2016-10-27 01:34:09 +03:00
submit-checklist
2016-09-21 14:40:21 +03:00
kernel-docs
2018-10-18 02:45:32 +03:00
deprecated
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>
2019-08-16 00:25:05 +03:00
embargoed-hardware-issues
2019-10-01 21:25:32 +03:00
maintainers
2022-03-04 21:14:18 +03:00
researcher-guidelines
2016-10-27 01:34:09 +03:00
These are some overall technical guides that have been put here for now for
lack of a better place.
.. toctree ::
2016-10-27 01:41:05 +03:00
:maxdepth: 1
2016-10-27 01:34:09 +03:00
2016-09-21 14:40:21 +03:00
applying-patches
adding-syscalls
magic-number
volatile-considered-harmful
2019-10-03 21:58:42 +03:00
botching-up-ioctls
2018-05-07 12:35:39 +03:00
clang-format
2019-11-23 05:33:28 +03:00
../riscv/patch-acceptance
2020-07-18 19:50:59 +03:00
../core-api/unaligned-memory-access
2016-09-21 14:40:21 +03:00
2016-10-26 09:23:16 +03:00
.. only :: subproject and html
Indices
=======
* :ref: `genindex`
