Documentation: Add guidance on CONFIG default value
Subsystems (4)
cover Documentation: Add guidance on CONFIG default value
From: "Darren Hart (VMware)" <[email protected]>
Document the preference for "default n" in kconfig-language.txt, and reference that in the submit-checklist.rst.
Darren Hart (VMware) (2):
Documentation/kbuild: Add guidance for the use of default Documentation/process: Add CONFIG default value to submit-checklist
Documentation/kbuild/kconfig-language.txt | 21 +++++++++++++++++++++ Documentation/process/submit-checklist.rst | 4 +++- 2 files changed, 24 insertions(+), 1 deletion(-)
Signature · 1 line
2.9.4
PATCH 1/2 Documentation/kbuild: Add guidance for the use of default
From: "Darren Hart (VMware)" <[email protected]>
Document the preference [1] for new CONFIG options to "default n" (or not use default at all) in order to minimizes changes to the config, especially to avoid "make oldconfig" growing unnecessarily from release to release.
Document the exceptions where it is acceptable to use "default y/m" for new CONFIG options.
1. https://lkml.org/lkml/2017/11/18/257
--- Documentation/kbuild/kconfig-language.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
Documentation/kbuild/kconfig-language.txt +21 -0
@@ -77,6 +77,27 @@ applicable everywhere (see syntax). Optionally, dependencies only for this default value can be added with "if". + The default value deliberately defaults to 'n' in order to avoid bloating the + build. With few exceptions, new config options should not change this. The + intent is for "make oldconfig" to add as little as possible to the config from + release to release. + + Note: + Things that merit "default y/m" include: + + a) A new Kconfig option for something that used to always be built + should be "default y". + + b) A new gatekeeping Kconfig option that hides/shows other Kconfig + options (but does not generate any code of its own), should be + "default y" so people will see those other options. + + c) Sub-driver behavior or similar options for a driver that is + "default n". This allows you to provide sane defaults. + + d) Hardware or infrastructure that everybody expects, such as CONFIG_NET + or CONFIG_BLOCK. These are rare exceptions. + - type definition + default value: "def_bool"/"def_tristate" <expr> ["if" <expr>] This is a shorthand notation for a type definition plus a value.
Signature · 1 line
2.9.4
PATCH 2/2 Documentation/process: Add CONFIG default value to submit-checklist
In reply to Darren HartFrom: "Darren Hart (VMware)" <[email protected]>
Add default value review to the submit checklist, referring to the preference for "default n" from the previous patch added to Documentation/kbuild/kconfig-language.txt.
--- Documentation/process/submit-checklist.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/process/submit-checklist.rst +3 -1
@@ -37,7 +37,9 @@ and elsewhere regarding submitting Linux kernel patches. 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. +6) 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 + ``Documentation/kbuild/kconfig-language.txt`` Menu attributes: default value. 7) All new ``Kconfig`` options have help text.
Signature · 1 line
2.9.4
Jonathan Corbet
maintainerQuoted 2 lines · On Mon, 20 Nov 2017 14:39:32 -0800 Darren Hart <[email protected]> wrote:
Document the preference for "default n" in kconfig-language.txt, and reference that in the
submit-checklist.rst.
I've (finally) applied the pair to the docs tree, thanks.
jon