There has been some confusion since checkpatch started warning about bool
use in structures, and people have been avoiding using it.

Many people feel there is still a legitimate place for bool in structures,
so provide some guidance on bool usage derived from the entire thread that
spawned the checkpatch warning.

Link: https://lkml.kernel.org/r/CA+55aFwVZk1OfB9T2v014PTAKFhtVan_Zj2dOjnCy3x6E4UJfA@mail.gmail.comSigned-off-by: NJoe Perches <joe@perches.com>
Acked-by: NJoe Perches <joe@perches.com>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJoey Pabalinas <joeypabalinas@gmail.com>
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Fix Sphinx warning in coding-style.rst:

Documentation/process/coding-style.rst:446: WARNING: Inline interpreted text or phrase reference start-string without end-string.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

In emacs 23.1 support for directory-local variables was added (see also
https://lists.gnu.org/archive/html/info-gnu-emacs/2009-07/msg00000.html).
Simplify the settings in coding-style.rst by using that feature.
Additionally, do not inherit any settings from emacs' linux coding style
to minimize dependencies on the version of emacs that is being used.

I have verified with several large and nontrivial kernel source files
that the new settings format code according to what checkpatch expects.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alison Chaiken <alison@she-devel.com>
Cc: Joe Perches <joe@perches.com>
Cc: Federico Vaga <federico.vaga@vaga.pv.it>
Cc: Geyslan G. Bem <geyslan@gmail.com>
Cc: Tiago Natel de Moura <tiago4orion@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

`extern' with function prototypes makes lines longer and creates more
characters on the screen.

Do not bug people with checkpatch.pl warnings for now as fallout can be
devastating.

Link: http://lkml.kernel.org/r/20181101134153.GA29267@avx2Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some documents are refering to others without links. With this
patch I add those missing links.

This patch affects only documents under process/ and labels where
necessary.
Signed-off-by: NFederico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

clang-format is a tool to format C/C++/...  code according to a set of
rules and heuristics.  Like most tools, it is not perfect nor covers
every single case, but it is good enough to be helpful.

In particular, it is useful for quickly re-formatting blocks of code
automatically, for reviewing full files in order to spot coding style
mistakes, typos and possible improvements.  It is also handy for sorting
``#includes``, for aligning variables and macros, for reflowing text and
other similar tasks.  It also serves as a teaching tool/guide for
newcomers.

The tool itself has been already included in the repositories of popular
Linux distributions for a long time.  The rules in this file are
intended for clang-format >= 4, which is easily available in most
distributions.

This commit adds the configuration file that contains the rules that the
tool uses to know how to format the code according to the kernel coding
style.  This gives us several advantages:

  * clang-format works out of the box with reasonable defaults;
    avoiding that everyone has to re-do the configuration.

  * Everyone agrees (eventually) on what is the most useful default
    configuration for most of the kernel.

  * If it becomes commonplace among kernel developers, clang-format
    may feel compelled to support us better. They already recognize
    the Linux kernel and its style in their documentation and in one
    of the style sub-options.

Some of clang-format's features relevant for the kernel are:

  * Uses clang's tooling support behind the scenes to parse and rewrite
    the code. It is not based on ad-hoc regexps.

  * Supports reasonably well the Linux kernel coding style.

  * Fast enough to be used at the press of a key.

  * There are already integrations (either built-in or third-party)
    for many common editors used by kernel developers (e.g. vim,
    emacs, Sublime, Atom...) that allow you to format an entire file
    or, more usefully, just your selection.

  * Able to parse unified diffs -- you can, for instance, reformat
    only the lines changed by a git commit.

  * Able to reflow text comments as well.

  * Widely supported and used by hundreds of developers in highly
    complex projects and organizations (e.g. the LLVM project itself,
    Chromium, WebKit, Google, Mozilla...). Therefore, it will be
    supported for a long time.

See more information about the tool at:

    https://clang.llvm.org/docs/ClangFormat.html
    https://clang.llvm.org/docs/ClangFormatStyleOptions.html

Link: http://lkml.kernel.org/r/20180318171632.qfkemw3mwbcukth6@gmail.comSigned-off-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add another example of required braces when using a compound statement in
a loop.
Signed-off-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The "\n\t" sequence needs to be quoted or it will not render properly.

[jc: no signoff from the author, but it's trivial]
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Having the kernel-documentation at the topmost level doesn't
allow generating a separate PDF file for it. Also, makes harder
to add extra contents. So, place it on a sub-dir.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Commit 865a1caa ("CodingStyle: Clarify and complete chapter 7")
renamed the label "out_buffer" to "out_free_buffer", but missed to
change this line.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right places.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add several documents to the development-process ReST book.

As we don't want renames, use symlinks instead, keeping those
documents on their original place.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Recent discussion has made it clear that there is no community consensus on
this particular rule.  Remove it now, lest it inspire yet another set of
unwanted "cleanup" patches.

This partially reverts 865a1caa (CodingStyle: Clarify and complete
chapter 7).

Cc: Jean Delvare <jdelvare@suse.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Add cross references for the documents mentioned at HOWTO and
are under the Documentation/ directory, using the ReST notation.

It should be noticed that HOWTO also mentions the /README file.
We opted to not touch it, for now, as making it build on
Sphinx would require it to be moved to a Documentation/foo
directory.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

There are two places there where there are notes that should
be highlighted. So, use the ReST note markup for such texts.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Sphinx doesn't accept underline markups by purpose.
While there are ways to support underline via CSS, this won't
be portable with non-html outputs.

As we want CodingStyle to do emphasis, replace _foo_ by **foo**,
using bold emphasis.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

On Sphinx/ReST notation, ``foo`` means that foo will be will be
marked as inline literal, effectively making it to be presented
as a monospaced font.

As we want this document to be parsed by Sphinx, instead of using
"foo", use ``foo`` for the names that are literal, because it is an
usual typographic convention to use monospaced fonts for functions
and language commands on documents, and we're following such
convention on the other ReST books.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

- Fix all chapter identation;
- add c blocks where needed;
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Because Linus may still be reading source code on greenbar paper
instead of color terminals with code syntax highlighting and
appropriate font decorations.

Link: http://lkml.kernel.org/r/CA+55aFyQYJerovMsSoSKS7PessZBr4vNp-3QUUwhqk4A4_jcbg@mail.gmail.comSigned-off-by: NJoe Perches <joe@perches.com>

Chapter 7 (Centralized exiting of functions) of the coding style
documentation is unclear at times, and lacks some information (such
as the possibility to indent labels with a single space.) Clarify and
complete it.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Markus Elfring <elfring@users.sourceforge.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Now that the new Sphinx world order is taking over, the information in
kernel-doc-nano-HOWTO.txt is outmoded.  I hate to remove it altogether,
since it's one of those files that people expect to find.  But we can add a
warning and fix all the other pointers to it.
Reminded-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NThomas Gardner <tmg@fastmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Simple typo: "it" for "is".
Signed-off-by: NManuel Pégourié-Gonnard <mpg@elzevir.fr>
Cc: Trivial Patch Monkey <trivial@kernel.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Remove 2 broken links for programming reference books in Appendix I. After
a lookup on an Internet archives web site, it seems that these links have
been broken for around 3 months. We can then assume that they will not be
back up and safely remove them from the documentation.
Signed-off-by: NOlivier C. Larocque <olivier.c.larocque@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Fixes: f2027543 ('documentation: update CodingStyle on local variables naming in macros')
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Describe proper naming convention for local variables in macros
resembling functions.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Try to make coding style documentation look a bit more readable and
consistent with the following:

 - indent every code example in C to first tab-stop;
 - surround every code example with empty lines, both top and bottom;
 - remove empty lines where text looked way too spare;
 - do not indent examples in elisp and kconfig;
 - do not do any non-whitespace changes.
Signed-off-by: NPavel Kretov <firegurafiku@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Coding style description has a irregular mixture of tabs and spaces in two
places which is bad by any means and can possibly hurt somebody's sense
of beauty.
Signed-off-by: NPavel Kretov <firegurafiku@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Suggest to developers who use emacs that they turn on the
instantaneous trailing-whitespace warning feature.
Signed-off-by: NAlison Chaiken <alison_chaiken@mentor.com>
[jc: untabified to match its surroundings]
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

I added a paragraph on choosing label names, and updated the example
code to use a better label name.  I also cleaned up the example code to
more modern style by moving the allocation out of the initializer and
changing the NULL check.

Perhaps the most common type of error handling bug in the kernel is "one
err bugs".  CodingStyle already says that we should "avoid nesting" by
using error labels and one err style error handling tends to have
multiple indent levels, so this was already bad style.  But I've added a
new paragraph explaining how to avoid one err bugs by using multiple
error labels which is, hopefully, more clear.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
[jc: added GFP_KERNEL to kmalloc() call]
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Document several common practices and conventions regarding conditional
compilation, most notably the preference for ifdefs in headers rather
than .c files.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

There was a minor typo in the CodingStyle document where the word 'section'
had been spelled as 'secton'.
Signed-off-by: NRaymond L. Rivera <ray.l.rivera@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The pr_debug() and related debug print macros all differ from the normal
pr_XXX() macros, in that the normal ones print unconditionally, while
the debug macros are compiled out unless DEBUG is defined or
CONFIG_DYNAMIC_DEBUG is set.  This isn't obvious, and the only way to
find this out is either to review the actual printk.h code or to read
CodingStyle, and the message there doesn't highlight the fact.

Change Documentation/CodingStyle to clearly indicate that pr_debug() and
related debug printing macros behave differently than all other pr_XXX()
macros, and attempt to clarify when and where the different debug
printing methods might be used.

Add short comment to printk.h above the pr_XXX() macros indicating that
while these macros print unconditionally, pr_debug() does not.
Signed-off-by: NDan Streetman <ddstreet@ieee.org>
Cc: Joe Perches <joe@perches.com>
Cc: Fabian Frederick <fabf@skynet.be>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A surprising number of newbies interpret this section to mean that only
one return statement is allowed per function.  Part of the problem is that
the "one return statement per function" rule is an actual style guideline
that people are used to from other projects.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Rob Landley <rob@landley.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

CC: Rob Landley <rob@landley.net>
CC: Jiri Kosina <jkosina@suse.cz>
CC: Masanari Iida <standby24x7@gmail.com>
CC: Jason Wessel <jason.wessel@windriver.com>
CC: Richard L Maliszewski <richard.l.maliszewski@intel.com>
CC: Gang Wei <gang.wei@intel.com>
CC: Shane Wang <shane.wang@intel.com>
CC: Harry Wei <harryxiyou@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: NJason Wessel <jason.wessel@windriver.com>

The block comment style in net/ and drivers/net is non-standard.
Document it.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: "Allan, Bruce W" <bruce.w.allan@intel.com>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add the new kmalloc_array() to the list of general-purpose memory
allocators in chapter 14.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Acked-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NPekka Enberg <penberg@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After commit 38829dc9 ("Documentation/CodingStyle: flesh out if-else
examples") highlight that if _only_one_ branch of a conditional
statement is a single statement, then braces are to be used on both
branches.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Patch reviewers now recommend not splitting long user-visible strings,
such as printk messages, even if they exceed 80 columns.  This avoids
breaking grep.  However, that recommendation did not actually appear
anywhere in Documentation/CodingStyle.

See, for example, the thread at
  http://news.gmane.org/find-root.php?message_id=%3c1312215262.11635.15.camel%40Joe%2dLaptop%3eSigned-off-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>