Workflows Archive mirror
 help / color / mirror / Atom feed
From: Yueh-Shun Li <shamrocklee@posteo.net>
To: Jonathan Corbet <corbet@lwn.net>,
	Hu Haowen <src.res.211@gmail.com>, Alex Shi <alexs@kernel.org>,
	Yanteng Si <siyanteng@loongson.cn>,
	Randy Dunlap <rdunlap@infradead.org>
Cc: Yueh-Shun Li <shamrocklee@posteo.net>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] coding-style: recommend reusing macros from split headers instead of kernel.h
Date: Mon,  8 Jan 2024 16:03:21 +0000	[thread overview]
Message-ID: <20240108160746.177421-1-shamrocklee@posteo.net> (raw)
In-Reply-To: <107b6b5e-ca14-4b2b-ba2e-38ecd74c0ad3@infradead.org>

Dear Maintainers,

This series of patches targets the "Linux kernel coding style"
documentation and recommend reusing macros inside the include/linux
directory instead of the obsolete header "include/linux/kernel.h".

This addresses the issue 'Irrelevant documentation recommending the use
of "include/linux/kernel.h"'[1][2] and help deprecating "kernel.h".

If applied, developers will no longer be confused by the contradiction
between "Linux kernel style guide" suggestions and the deprecation
notice on top of "kernel.h".

There's also a patch that adds an example to show how reusing macro
definition from shared headers help prevent naming collisions.

This series contains the update to the zh_TW and zh_CN translation of
the corresponding documentation changes.

Best regards,

Shamrock

[1]: https://lore.kernel.org/linux-doc/bc63acd7ef43bdd8d9609fa48dbf92f9@posteo.net/
[2]: https://lore.kernel.org/linux-doc/107b6b5e-ca14-4b2b-ba2e-38ecd74c0ad3@infradead.org/

Yueh-Shun Li (4):
  coding-style: recommend split headers instead of kernel.h
  coding-style: show how reusing macros prevents naming collisions
  doc/zh_TW: coding-style: update content for section 18
  doc/zh_CN: coding-style: update content of section 18

 Documentation/process/coding-style.rst        | 41 +++++++++++++++----
 .../zh_CN/process/coding-style.rst            | 39 ++++++++++++++----
 .../zh_TW/process/coding-style.rst            | 39 ++++++++++++++----
 3 files changed, 95 insertions(+), 24 deletions(-)

-- 
2.42.0


       reply	other threads:[~2024-01-08 16:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <107b6b5e-ca14-4b2b-ba2e-38ecd74c0ad3@infradead.org>
2024-01-08 16:03 ` Yueh-Shun Li [this message]
2024-01-08 16:03   ` [PATCH 1/4] coding-style: recommend split headers instead of kernel.h Yueh-Shun Li
2024-01-08 16:03   ` [PATCH 2/4] coding-style: show how reusing macros prevents naming collisions Yueh-Shun Li
2024-01-08 16:28     ` Jonathan Corbet
2024-01-08 18:23       ` Yueh-Shun Li
2024-01-08 18:27         ` Jonathan Corbet
2024-01-08 19:37 ` [PATCH v2 0/3] coding-style: recommend reusing macros from split headers instead of kernel.h Yueh-Shun Li
2024-01-08 20:17   ` Yueh-Shun Li
2024-01-08 20:18 ` [PATCH v3 0/1] " Yueh-Shun Li
2024-01-08 20:22   ` [PATCH v3 1/1] coding-style: recommend " Yueh-Shun Li
2024-01-28  6:26     ` Randy Dunlap
2024-05-06 23:17       ` Yueh-Shun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240108160746.177421-1-shamrocklee@posteo.net \
    --to=shamrocklee@posteo.net \
    --cc=alexs@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=siyanteng@loongson.cn \
    --cc=src.res.211@gmail.com \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).