linux-kernel - [PATCH v5 31/31] Documentation: kconfig: add recommended way to describe compiler support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1527499328-13213-32-git-send-email-yamada.masahiro@socionext.com>
Date:   Mon, 28 May 2018 18:22:08 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     linux-kbuild@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Nicholas Piggin <npiggin@...il.com>,
        "Luis R . Rodriguez" <mcgrof@...e.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Ulf Magnusson <ulfalizer@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: [PATCH v5 31/31] Documentation: kconfig: add recommended way to describe compiler support

It would be nice if the source code is written in the same style.
This proposes the convention for describing the compiler capability
in Kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
---

This is not a technical issue, but it would be nice if everybody
follows the same coding style.

Without any documemation, people may write the code in their own way.
For example, there could be some possibilities for the option naming.

  CC_HAS_
  CC_SUPPORTS_
  CC_HAVE_
  ...

IMHO, CC_HAS_ is short and enough to understand the meaning.

CC_SUPPORTS_ is also good, but I personally prefer the shorter one.

Comments are appreciated.


Changes in v5:
  - Newly added

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/kbuild/kconfig-language.txt | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index 0e966e8..a4eb018 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -473,6 +473,24 @@ config option to 'y' no matter the dependencies.
 The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
 situation where select forces a symbol equals to 'y'.
 
+Adding features that need compiler support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are several features that need compiler support. The recommended way
+to describe the dependency on the compiler feature is to use "depends on"
+followed by a test macro.
+
+config CC_STACKPROTECTOR
+	bool "Stack Protector buffer overflow detection"
+	depends on $(cc-option,-fstack-protector)
+	...
+
+If you need to expose a compiler capability to makefiles and/or C source files,
+CC_HAS_ is the recommended prefix for the config option.
+
+config CC_HAS_STACKPROTECTOR_NONE
+	def_bool $(cc-option,-fno-stack-protector)
+
 Build as module only
 ~~~~~~~~~~~~~~~~~~~~
 To restrict a component build to module-only, qualify its config symbol
-- 
2.7.4