mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-23 20:53:53 +08:00
8033fe65a6
We want all uses of memory barriers to be explained in the source code. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
91 lines
3.5 KiB
Plaintext
91 lines
3.5 KiB
Plaintext
Linux Kernel patch submission checklist
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Here are some basic things that developers should do if they want to see their
|
|
kernel patch submissions accepted more quickly.
|
|
|
|
These are all above and beyond the documentation that is provided in
|
|
Documentation/SubmittingPatches and elsewhere regarding submitting Linux
|
|
kernel patches.
|
|
|
|
|
|
1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
|
|
=n. No gcc warnings/errors, no linker warnings/errors.
|
|
|
|
2: Passes allnoconfig, allmodconfig
|
|
|
|
3: Builds on multiple CPU architectures by using local cross-compile tools
|
|
or something like PLM at OSDL.
|
|
|
|
4: ppc64 is a good architecture for cross-compilation checking because it
|
|
tends to use `unsigned long' for 64-bit quantities.
|
|
|
|
5: Check your patch for general style as detailed in
|
|
Documentation/CodingStyle. Check for trivial violations with the
|
|
patch style checker prior to submission (scripts/checkpatch.pl).
|
|
You should be able to justify all violations that remain in
|
|
your patch.
|
|
|
|
6: Any new or modified CONFIG options don't muck up the config menu.
|
|
|
|
7: All new Kconfig options have help text.
|
|
|
|
8: Has been carefully reviewed with respect to relevant Kconfig
|
|
combinations. This is very hard to get right with testing -- brainpower
|
|
pays off here.
|
|
|
|
9: Check cleanly with sparse.
|
|
|
|
10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
|
|
that they find. Note: checkstack does not point out problems explicitly,
|
|
but any one function that uses more than 512 bytes on the stack is a
|
|
candidate for change.
|
|
|
|
11: Include kernel-doc to document global kernel APIs. (Not required for
|
|
static functions, but OK there also.) Use 'make htmldocs' or 'make
|
|
mandocs' to check the kernel-doc and fix any issues.
|
|
|
|
12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
|
|
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
|
|
CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
|
|
enabled.
|
|
|
|
13: Has been build- and runtime tested with and without CONFIG_SMP and
|
|
CONFIG_PREEMPT.
|
|
|
|
14: If the patch affects IO/Disk, etc: has been tested with and without
|
|
CONFIG_LBD.
|
|
|
|
15: All codepaths have been exercised with all lockdep features enabled.
|
|
|
|
16: All new /proc entries are documented under Documentation/
|
|
|
|
17: All new kernel boot parameters are documented in
|
|
Documentation/kernel-parameters.txt.
|
|
|
|
18: All new module parameters are documented with MODULE_PARM_DESC()
|
|
|
|
19: All new userspace interfaces are documented in Documentation/ABI/.
|
|
See Documentation/ABI/README for more information.
|
|
Patches that change userspace interfaces should be CCed to
|
|
linux-api@vger.kernel.org.
|
|
|
|
20: Check that it all passes `make headers_check'.
|
|
|
|
21: Has been checked with injection of at least slab and page-allocation
|
|
failures. See Documentation/fault-injection/.
|
|
|
|
If the new code is substantial, addition of subsystem-specific fault
|
|
injection might be appropriate.
|
|
|
|
22: Newly-added code has been compiled with `gcc -W' (use "make
|
|
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
|
|
finding bugs like "warning: comparison between signed and unsigned".
|
|
|
|
23: Tested after it has been merged into the -mm patchset to make sure
|
|
that it still works with all of the other queued patches and various
|
|
changes in the VM, VFS, and other subsystems.
|
|
|
|
24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the
|
|
source code that explains the logic of what they are doing and why.
|