docs: submit-checklist: use subheadings

During review (see Link), Jani Nikula suggested to use proper subheadings
instead of using italics to indicate the different new top-level
categories in the checklist. Further the top heading should follow the
common scheme.

Use subheadings. Adjust to common heading adornment.

Link: https://lore.kernel.org/linux-doc/87o7c3mlwb.fsf@intel.com/
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20240229030743.9125-3-lukas.bulwahn@gmail.com>
This commit is contained in:
Lukas Bulwahn 2024-02-29 04:07:42 +01:00 committed by Jonathan Corbet
parent 5969fbf302
commit 47c67ec1e8
1 changed files with 14 additions and 12 deletions

View File

@ -1,7 +1,8 @@
.. _submitchecklist: .. _submitchecklist:
=======================================
Linux Kernel patch submission checklist Linux Kernel patch submission checklist
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =======================================
Here are some basic things that developers should do if they want to see their Here are some basic things that developers should do if they want to see their
kernel patch submissions accepted more quickly. kernel patch submissions accepted more quickly.
@ -10,8 +11,8 @@ These are all above and beyond the documentation that is provided in
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
and elsewhere regarding submitting Linux kernel patches. and elsewhere regarding submitting Linux kernel patches.
Review your code
*Review your code:* ================
1) If you use a facility then #include the file that defines/declares 1) If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones that facility. Don't depend on other header files pulling in ones
@ -24,8 +25,8 @@ and elsewhere regarding submitting Linux kernel patches.
comment in the source code that explains the logic of what they are doing comment in the source code that explains the logic of what they are doing
and why. and why.
Review Kconfig changes
*Review Kconfig changes:* ======================
1) Any new or modified ``CONFIG`` options do not muck up the config menu and 1) Any new or modified ``CONFIG`` options do not muck up the config menu and
default to off unless they meet the exception criteria documented in default to off unless they meet the exception criteria documented in
@ -37,7 +38,8 @@ and elsewhere regarding submitting Linux kernel patches.
combinations. This is very hard to get right with testing---brainpower combinations. This is very hard to get right with testing---brainpower
pays off here. pays off here.
*Provide documentation:* Provide documentation
=====================
1) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs. 1) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs.
(Not required for static functions, but OK there also.) (Not required for static functions, but OK there also.)
@ -57,8 +59,8 @@ and elsewhere regarding submitting Linux kernel patches.
6) If any ioctl's are added by the patch, then also update 6) If any ioctl's are added by the patch, then also update
``Documentation/userspace-api/ioctl/ioctl-number.rst``. ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
Check your code with tools
*Check your code with tools:* ==========================
1) Check for trivial violations with the patch style checker prior to 1) Check for trivial violations with the patch style checker prior to
submission (``scripts/checkpatch.pl``). submission (``scripts/checkpatch.pl``).
@ -72,8 +74,8 @@ and elsewhere regarding submitting Linux kernel patches.
but any one function that uses more than 512 bytes on the stack is a but any one function that uses more than 512 bytes on the stack is a
candidate for change. candidate for change.
Build your code
*Build your code:* ===============
1) Builds cleanly: 1) Builds cleanly:
@ -107,8 +109,8 @@ and elsewhere regarding submitting Linux kernel patches.
``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``). ``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``).
Test your code
*Test your code:* ==============
1) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 1) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,