Development: Linux Kernel patch submittal checklist - Revision history

CityK: add cat.

2009-01-15T23:25:31Z

add cat.

← Older revision		Revision as of 23:25, 15 January 2009
Line 24:		Line 24:
	7: All new Kconfig options have help text.		7: All new Kconfig options have help text.

		+
		+	[[Category:Development]]
	8: Has been carefully reviewed with respect to relevant Kconfig combinations. This is very hard to get right with testing -- brainpower pays off here.		8: Has been carefully reviewed with respect to relevant Kconfig combinations. This is very hard to get right with testing -- brainpower pays off here.

CityK: add description and format

2009-01-15T00:53:41Z

add description and format

← Older revision		Revision as of 00:53, 15 January 2009
Line 1:		Line 1:
		+	The following content is a copy of the <code>/usr/src/linux/Documentation/SubmitChecklist</code> file (modified slightly for visual presentation). A current copy can also be found online [http://lxr.linux.no/source/Documentation/SubmitChecklist here].
		+
		+
		+	<center>'''Linux Kernel patch submission checklist'''</center>
		+
	Here are some basic things that developers should do if they want to see their kernel patch submissions accepted more quickly.		Here are some basic things that developers should do if they want to see their kernel patch submissions accepted more quickly.

	All of these suggestions go above and beyond what is outlined in the documentation provided in		All of these suggestions go above and beyond what is outlined in the documentation provided in
-	Documentation/SubmittingPatches and elsewhere regarding submitting Linux kernel patches.	+	[[Development: Submitting Patches\|Documentation/SubmittingPatches]] and elsewhere regarding submitting Linux kernel patches.

CityK: 4 revision(s)

2008-11-20T02:48:37Z

4 revision(s)

← Older revision

Revision as of 02:48, 20 November 2008

CityK: minor edits

2008-10-16T00:49:59Z

minor edits

← Older revision		Revision as of 00:49, 16 October 2008
Line 1:		Line 1:
-	~~== Linux Kernel patch submittal checklist ==~~	+	Here are some basic things that developers should do if they want to see their kernel patch submissions accepted more quickly.
-		+
-	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~~.	+

		+	All of these suggestions go above and beyond what is outlined in the documentation provided in
		+	Documentation/SubmittingPatches and elsewhere regarding submitting Linux kernel patches.

CityK: CheckList moved to Development: Linux Kernel patch submittal checklist: name

2008-10-16T00:48:09Z

CheckList moved to Development: Linux Kernel patch submittal checklist: name

← Older revision

Revision as of 00:48, 16 October 2008

Elronxenu: grammar

2007-03-12T11:19:47Z

grammar

Mauro Carvalho Chehab at 13:50, 7 February 2007

2007-02-07T13:50:40Z

New page

== Linux Kernel patch sumbittal 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: Matches kernel coding style(!)

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.

20: Check that it all passes `make headers_check'.

21: Has been checked with injection of at least slab and page-allocation fauilures. 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'. This will generate lots of noise, but is good for finding bugs like "warning: comparisonbetween signed and unsigned".

← Older revision		Revision as of 11:19, 12 March 2007
Line 1:		Line 1:
-	== Linux Kernel patch ~~sumbittal~~ checklist ==	+	== Linux Kernel patch submittal 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
Line 14:		Line 14:
	2: Passes allnoconfig, allmodconfig		2: Passes allnoconfig, allmodconfig

-	3: Builds on multiple CPU architectures by using local cross-compile tools or something like PLM at OSDL.	+	3: Builds on multiple CPU architectures by using local cross-compile tools or something like PLM at OSDL (http://plm.testing.osdl.org/).

	4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities.		4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities.
Line 30:		Line 30:
	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.		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.	+	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.		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.
Line 36:		Line 36:
	13: Has been build- and runtime tested with and without CONFIG_SMP and CONFIG_PREEMPT.		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.	+	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.		15: All codepaths have been exercised with all lockdep features enabled.
Line 52:		Line 52:
	21: Has been checked with injection of at least slab and page-allocation fauilures. See Documentation/fault-injection/. If the new code is substantial, addition of subsystem-specific fault injection might be appropriate.		21: Has been checked with injection of at least slab and page-allocation fauilures. 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'. This will generate lots of noise, but is good for finding bugs like "warning: ~~comparisonbetween~~ signed and unsigned".	+	22: Newly-added code has been compiled with `gcc -W'. This will generate lots of noise, but is good for finding bugs like "warning: comparison between signed and unsigned".