Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/agents/coding-style.rst | 35 +++++++++++++++++++++++++++
Documentation/agents/index.rst | 3 ++-
Documentation/agents/main.rst | 5 ++++
3 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 Documentation/agents/coding-style.rst
diff --git a/Documentation/agents/coding-style.rst b/Documentation/agents/coding-style.rst
new file mode 100644
index 000000000000..b0332ee91e6c
--- /dev/null
+++ b/Documentation/agents/coding-style.rst
@@ -0,0 +1,35 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================
+Linux Kernel Coding Style
+==========================
+
+Essential coding style documentation and rules for Linux kernel development.
+
+Coding Style Documentation
+--------------------------
+
+The comprehensive guide to Linux kernel coding style, covering indentation, naming conventions, functions, and more.
+
+See :ref:`Documentation/process/coding-style.rst <codingstyle>`
+
+Programming Language
+--------------------
+
+Information about the C programming language dialect used in the kernel, compiler options, and attributes.
+
+See :ref:`Documentation/process/programming-language.rst <programming_language>`
+
+Explicit Coding Rules
+---------------------
+
+The following rules must be followed when writing kernel code:
+
+**No trailing whitespaces**
+ Never leave whitespace at the end of lines. Git will warn about patches that introduce trailing whitespace.
+
+**80 character line limit**
+ The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information.
+
+**8 character tabs for indents**
+ Tabs are 8 characters, and thus indentations are also 8 characters. The kernel uses tabs for indentation, never spaces. This makes code structure clear and warns when nesting becomes too deep.
\ No newline at end of file
diff --git a/Documentation/agents/index.rst b/Documentation/agents/index.rst
index 2737ab62efa0..354af3f025e5 100644
--- a/Documentation/agents/index.rst
+++ b/Documentation/agents/index.rst
@@ -8,4 +8,5 @@ Agents
:maxdepth: 1
main
- core
\ No newline at end of file
+ core
+ coding-style
\ No newline at end of file
diff --git a/Documentation/agents/main.rst b/Documentation/agents/main.rst
index 34f13d0b975a..8e0463794b76 100644
--- a/Documentation/agents/main.rst
+++ b/Documentation/agents/main.rst
@@ -10,3 +10,8 @@ Core Development Process
------------------------
For essential kernel development documentation, see :doc:`core`
+
+Coding Style
+------------
+
+For coding style guidelines and rules, see :doc:`coding-style`
--
2.39.5On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote: > +++ b/Documentation/agents/coding-style.rst All of this is redundant. > +**No trailing whitespaces** > + Never leave whitespace at the end of lines. Git will warn about patches that introduce trailing whitespace. If this isn't covered elsewhere in Documentation/, it should be. :) Also, "all files end with a newline" > +**80 character line limit** > + The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. And this is why redundancy is bad: our line limit is 100, not 80. -- Kees Cook
On Sun, Jul 27, 2025 at 07:40:36PM -0700, Kees Cook wrote: >On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote: >> +++ b/Documentation/agents/coding-style.rst > >All of this is redundant. > >> +**No trailing whitespaces** >> + Never leave whitespace at the end of lines. Git will warn about patches that introduce trailing whitespace. > >If this isn't covered elsewhere in Documentation/, it should be. :) >Also, "all files end with a newline" This is a funny one. Yes, it's in the docs, but from my experiments the tools kept "ignoring" this instruction. I've asked around and the explanation that I got is that to manipulate files agents call out to external tools, and often these interactions are not perfect (if you use Claude you might have seen errors such as "Error: Found 2 matches of the string to replace, but replace_all is false."). The end result is that those mis-interactions end up doing something that the agent itself didn't intend on doing, such as adding trailing whitespaces or having super long lines. If we call these common issues out explicitly then the agent would also look back at the code it generated to make sure that it doesn't actually have any of these issues after code was edited. >> +**80 character line limit** >> + The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. > >And this is why redundancy is bad: our line limit is 100, not 80. Hrm, it is? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n104 claims: The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. -- Thanks, Sasha
On Mon, Jul 28, 2025 at 01:10:25AM -0400, Sasha Levin wrote:
> On Sun, Jul 27, 2025 at 07:40:36PM -0700, Kees Cook wrote:
> > On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote:
> > > +**80 character line limit**
> > > + The preferred limit on the length of a single line is 80 columns.
>
> Hrm, it is?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n104
> claims:
>
> The preferred limit on the length of a single line is 80 columns.
>
> Statements longer than 80 columns should be broken into sensible chunks,
> unless exceeding 80 columns significantly increases readability and does
> not hide information.
That's true, it's not called out well enough. 80 is "preferred
limit" but not the hard limit, which is 100. See commit bdc48fa11e46
("checkpatch/coding-style: deprecate 80-column warning")
-Kees
--
Kees Cook
On Sun, Jul 27, 2025 at 10:21:40PM -0700, Kees Cook wrote:
>On Mon, Jul 28, 2025 at 01:10:25AM -0400, Sasha Levin wrote:
>> On Sun, Jul 27, 2025 at 07:40:36PM -0700, Kees Cook wrote:
>> > On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote:
>> > > +**80 character line limit**
>> > > + The preferred limit on the length of a single line is 80 columns.
>>
>> Hrm, it is?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n104
>> claims:
>>
>> The preferred limit on the length of a single line is 80 columns.
>>
>> Statements longer than 80 columns should be broken into sensible chunks,
>> unless exceeding 80 columns significantly increases readability and does
>> not hide information.
>
>That's true, it's not called out well enough. 80 is "preferred
>limit" but not the hard limit, which is 100. See commit bdc48fa11e46
>("checkpatch/coding-style: deprecate 80-column warning")
Sadly it doesn't look like I'm the only one who's confused here:
https://lore.kernel.org/all/?q=%22checkpatch%2Fcoding-style%3A+deprecate+80-column+warning%22
--
Thanks,
Sasha
On 28/07/2025 08:03, Sasha Levin wrote:
> On Sun, Jul 27, 2025 at 10:21:40PM -0700, Kees Cook wrote:
>> On Mon, Jul 28, 2025 at 01:10:25AM -0400, Sasha Levin wrote:
>>> On Sun, Jul 27, 2025 at 07:40:36PM -0700, Kees Cook wrote:
>>>> On Sun, Jul 27, 2025 at 03:58:01PM -0400, Sasha Levin wrote:
>>>>> +**80 character line limit**
>>>>> + The preferred limit on the length of a single line is 80 columns.
>>>
>>> Hrm, it is?
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n104
>>> claims:
>>>
>>> The preferred limit on the length of a single line is 80 columns.
>>>
>>> Statements longer than 80 columns should be broken into sensible chunks,
>>> unless exceeding 80 columns significantly increases readability and does
>>> not hide information.
>>
>> That's true, it's not called out well enough. 80 is "preferred
>> limit" but not the hard limit, which is 100. See commit bdc48fa11e46
>> ("checkpatch/coding-style: deprecate 80-column warning")
>
> Sadly it doesn't look like I'm the only one who's confused here:
> https://lore.kernel.org/all/?q=%22checkpatch%2Fcoding-style%3A+deprecate+80-column+warning%22
>
I pop up there a lot, but there is no confusion. I am (and maybe we are
all?) well aware that checkpatch hard limit is 100 as explained also here:
https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0edf21@kernel.org/
But the coding style still says that preferred length limit is 80.
Checkpatch is not a coding style. Coding style document is describing
the coding style...
People trust checkpatch way too much, thus its hard limit was raised.
Some maintainers also agree with that, yet it does not invalidate what
coding style document says.
Best regards,
Krzysztof
On Wed, 30 Jul 2025 11:31:35 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> I pop up there a lot, but there is no confusion. I am (and maybe we are
> all?) well aware that checkpatch hard limit is 100 as explained also here:
> https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0edf21@kernel.org/
>
> But the coding style still says that preferred length limit is 80.
> Checkpatch is not a coding style. Coding style document is describing
> the coding style...
>
> People trust checkpatch way too much, thus its hard limit was raised.
> Some maintainers also agree with that, yet it does not invalidate what
> coding style document says.
Yeah, I had a couple of patches that were sent to me with everything at 100
max (comments and all). As I still have my windows set to 80 columns by
default, I find it annoying. I told them to fix it and resubmit.
But a break here and there where it makes it look a little better doesn't
bother me. For instance, the code in kernel/trace/trace.c has:
if (tif_need_resched())
trace_flags |= TRACE_FLAG_NEED_RESCHED;
if (test_preempt_need_resched())
trace_flags |= TRACE_FLAG_PREEMPT_RESCHED;
if (IS_ENABLED(CONFIG_ARCH_HAS_PREEMPT_LAZY) && tif_test_bit(TIF_NEED_RESCHED_LAZY))
trace_flags |= TRACE_FLAG_NEED_RESCHED_LAZY;
return (trace_flags << 16) | (min_t(unsigned int, pc & 0xff, 0xf)) |
(min_t(unsigned int, migration_disable_value(), 0xf)) << 4;
Where
if (IS_ENABLED(CONFIG_ARCH_HAS_PREEMPT_LAZY) && tif_test_bit(TIF_NEED_RESCHED_LAZY))
Breaks the 80 char limit, but honestly, I rather have that than:
if (tif_need_resched())
trace_flags |= TRACE_FLAG_NEED_RESCHED;
if (test_preempt_need_resched())
trace_flags |= TRACE_FLAG_PREEMPT_RESCHED;
if (IS_ENABLED(CONFIG_ARCH_HAS_PREEMPT_LAZY) &&
tif_test_bit(TIF_NEED_RESCHED_LAZY))
trace_flags |= TRACE_FLAG_NEED_RESCHED_LAZY;
return (trace_flags << 16) | (min_t(unsigned int, pc & 0xff, 0xf)) |
(min_t(unsigned int, migration_disable_value(), 0xf)) << 4;
As that breaks the flow.
Thus, to me it's a guideline. Try to stay under 80 but we don't need to be
draconian about it.
-- Steve
On Wed, 30 Jul 2025 11:31:35 +0200 Krzysztof Kozlowski wrote: > I pop up there a lot, but there is no confusion. I am (and maybe we are > all?) well aware that checkpatch hard limit is 100 as explained also here: > https://lore.kernel.org/all/df2e466a-cdaa-4263-ae16-7bf56c0edf21@kernel.org/ > > But the coding style still says that preferred length limit is 80. > Checkpatch is not a coding style. Coding style document is describing > the coding style... > > People trust checkpatch way too much, thus its hard limit was raised. > Some maintainers also agree with that, yet it does not invalidate what > coding style document says. Hear, hear!
© 2016 - 2025 Red Hat, Inc.