mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-23 08:56:59 +07:00
e7b4311ebc
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Link: https://lore.kernel.org/r/20200621133630.46435-1-grandmaster@al2klimov.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
185 lines
6.4 KiB
ReStructuredText
185 lines
6.4 KiB
ReStructuredText
.. _clangformat:
|
|
|
|
clang-format
|
|
============
|
|
|
|
``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.
|
|
|
|
``clang-format`` can be used for several purposes:
|
|
|
|
- Quickly reformat a block of code to the kernel style. Specially useful
|
|
when moving code around and aligning/sorting. See clangformatreformat_.
|
|
|
|
- Spot style mistakes, typos and possible improvements in files
|
|
you maintain, patches you review, diffs, etc. See clangformatreview_.
|
|
|
|
- Help you follow the coding style rules, specially useful for those
|
|
new to kernel development or working at the same time in several
|
|
projects with different coding styles.
|
|
|
|
Its configuration file is ``.clang-format`` in the root of the kernel tree.
|
|
The rules contained there try to approximate the most common kernel
|
|
coding style. They also try to follow :ref:`Documentation/process/coding-style.rst <codingstyle>`
|
|
as much as possible. Since not all the kernel follows the same style,
|
|
it is possible that you may want to tweak the defaults for a particular
|
|
subsystem or folder. To do so, you can override the defaults by writing
|
|
another ``.clang-format`` file in a subfolder.
|
|
|
|
The tool itself has already been included in the repositories of popular
|
|
Linux distributions for a long time. Search for ``clang-format`` in
|
|
your repositories. Otherwise, you can either download pre-built
|
|
LLVM/clang binaries or build the source code from:
|
|
|
|
https://releases.llvm.org/download.html
|
|
|
|
See more information about the tool at:
|
|
|
|
https://clang.llvm.org/docs/ClangFormat.html
|
|
|
|
https://clang.llvm.org/docs/ClangFormatStyleOptions.html
|
|
|
|
|
|
.. _clangformatreview:
|
|
|
|
Review files and patches for coding style
|
|
-----------------------------------------
|
|
|
|
By running the tool in its inline mode, you can review full subsystems,
|
|
folders or individual files for code style mistakes, typos or improvements.
|
|
|
|
To do so, you can run something like::
|
|
|
|
# Make sure your working directory is clean!
|
|
clang-format -i kernel/*.[ch]
|
|
|
|
And then take a look at the git diff.
|
|
|
|
Counting the lines of such a diff is also useful for improving/tweaking
|
|
the style options in the configuration file; as well as testing new
|
|
``clang-format`` features/versions.
|
|
|
|
``clang-format`` also supports reading unified diffs, so you can review
|
|
patches and git diffs easily. See the documentation at:
|
|
|
|
https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
|
|
|
|
To avoid ``clang-format`` formatting some portion of a file, you can do::
|
|
|
|
int formatted_code;
|
|
// clang-format off
|
|
void unformatted_code ;
|
|
// clang-format on
|
|
void formatted_code_again;
|
|
|
|
While it might be tempting to use this to keep a file always in sync with
|
|
``clang-format``, specially if you are writing new files or if you are
|
|
a maintainer, please note that people might be running different
|
|
``clang-format`` versions or not have it available at all. Therefore,
|
|
you should probably refrain yourself from using this in kernel sources;
|
|
at least until we see if ``clang-format`` becomes commonplace.
|
|
|
|
|
|
.. _clangformatreformat:
|
|
|
|
Reformatting blocks of code
|
|
---------------------------
|
|
|
|
By using an integration with your text editor, you can reformat arbitrary
|
|
blocks (selections) of code with a single keystroke. This is specially
|
|
useful when moving code around, for complex code that is deeply intended,
|
|
for multi-line macros (and aligning their backslashes), etc.
|
|
|
|
Remember that you can always tweak the changes afterwards in those cases
|
|
where the tool did not do an optimal job. But as a first approximation,
|
|
it can be very useful.
|
|
|
|
There are integrations for many popular text editors. For some of them,
|
|
like vim, emacs, BBEdit and Visual Studio you can find support built-in.
|
|
For instructions, read the appropiate section at:
|
|
|
|
https://clang.llvm.org/docs/ClangFormat.html
|
|
|
|
For Atom, Eclipse, Sublime Text, Visual Studio Code, XCode and other
|
|
editors and IDEs you should be able to find ready-to-use plugins.
|
|
|
|
For this use case, consider using a secondary ``.clang-format``
|
|
so that you can tweak a few options. See clangformatextra_.
|
|
|
|
|
|
.. _clangformatmissing:
|
|
|
|
Missing support
|
|
---------------
|
|
|
|
``clang-format`` is missing support for some things that are common
|
|
in kernel code. They are easy to remember, so if you use the tool
|
|
regularly, you will quickly learn to avoid/ignore those.
|
|
|
|
In particular, some very common ones you will notice are:
|
|
|
|
- Aligned blocks of one-line ``#defines``, e.g.::
|
|
|
|
#define TRACING_MAP_BITS_DEFAULT 11
|
|
#define TRACING_MAP_BITS_MAX 17
|
|
#define TRACING_MAP_BITS_MIN 7
|
|
|
|
vs.::
|
|
|
|
#define TRACING_MAP_BITS_DEFAULT 11
|
|
#define TRACING_MAP_BITS_MAX 17
|
|
#define TRACING_MAP_BITS_MIN 7
|
|
|
|
- Aligned designated initializers, e.g.::
|
|
|
|
static const struct file_operations uprobe_events_ops = {
|
|
.owner = THIS_MODULE,
|
|
.open = probes_open,
|
|
.read = seq_read,
|
|
.llseek = seq_lseek,
|
|
.release = seq_release,
|
|
.write = probes_write,
|
|
};
|
|
|
|
vs.::
|
|
|
|
static const struct file_operations uprobe_events_ops = {
|
|
.owner = THIS_MODULE,
|
|
.open = probes_open,
|
|
.read = seq_read,
|
|
.llseek = seq_lseek,
|
|
.release = seq_release,
|
|
.write = probes_write,
|
|
};
|
|
|
|
|
|
.. _clangformatextra:
|
|
|
|
Extra features/options
|
|
----------------------
|
|
|
|
Some features/style options are not enabled by default in the configuration
|
|
file in order to minimize the differences between the output and the current
|
|
code. In other words, to make the difference as small as possible,
|
|
which makes reviewing full-file style, as well diffs and patches as easy
|
|
as possible.
|
|
|
|
In other cases (e.g. particular subsystems/folders/files), the kernel style
|
|
might be different and enabling some of these options may approximate
|
|
better the style there.
|
|
|
|
For instance:
|
|
|
|
- Aligning assignments (``AlignConsecutiveAssignments``).
|
|
|
|
- Aligning declarations (``AlignConsecutiveDeclarations``).
|
|
|
|
- Reflowing text in comments (``ReflowComments``).
|
|
|
|
- Sorting ``#includes`` (``SortIncludes``).
|
|
|
|
They are typically useful for block re-formatting, rather than full-file.
|
|
You might want to create another ``.clang-format`` file and use that one
|
|
from your editor/IDE instead.
|