* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Jonathan Corbet @ 2025-12-22 22:01 UTC (permalink / raw)
To: Andi Shyti, Federico Vaga
Cc: linux-doc, linux-kernel, workflows, Andy Shevchenko
In-Reply-To: <klzag46p6mlqqdrogqofancqyjpvs5lmwa4m3tjszcgavdwa6s@nay2uuwpsvlt>
Andi Shyti <andi.shyti@kernel.org> writes:
> Hi Federico,
>
>> >-Il file di intestazione include/linux/kernel.h contiene un certo numero
>> >-di macro che dovreste usare piuttosto che implementarne una qualche variante.
>> >-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
>> >-macro:
>> >+I file header
>>
>> In Italian, the correct name for "header file" is "file di intestazione".
>> Please, don't replace correct Italian with *Itanglese* :)
>
> I absolutely disagree.
>
> If you open any C book, they are called 'header files', except
> for a few Italian technical books with excessively literal
> translations, where even non-translatable terms are translated.
I'm unconvinced about "file di intestazione" based on my own
understanding of the language... but, in a case like this, I will defer
to the creator and maintainer of the translation.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Documentation: Improve wording on requirements for a free Nitrokey
From: Jonathan Corbet @ 2025-12-22 22:31 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Konstantin Ryabitsev, workflows, linux-doc
In-Reply-To: <20251203074349.1826233-2-u.kleine-koenig@baylibre.com>
Uwe Kleine-König <u.kleine-koenig@baylibre.com> writes:
> "listed in MAINTAINERS" is not enough to qualify for the free Nitrokey
> Start. You have to be listed in an M: entry. Mention that to reduce
> confusion for reviewers who wonder why their application fails.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> Documentation/process/maintainer-pgp-guide.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied (finally), thanks.
jon
^ permalink raw reply
* [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Krzysztof Kozlowski @ 2025-12-23 14:27 UTC (permalink / raw)
To: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
It is already documented but people still send noticeable amount of
patches ignoring the rule - get_maintainers.pl does not work on
arm64/configs/defconfig or any other shared ARM defconfig.
Be more explicit, that one must not rely on typical/simple approach
here for getting To/Cc list.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
---
Documentation/process/maintainer-soc.rst | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 3ba886f52a51..014c639022b2 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -57,8 +57,10 @@ Submitting Patches for Given SoC
All typical platform related patches should be sent via SoC submaintainers
(platform-specific maintainers). This includes also changes to per-platform or
-shared defconfigs (scripts/get_maintainer.pl might not provide correct
-addresses in such case).
+shared defconfigs. Note that scripts/get_maintainer.pl might not provide
+correct addresses for the shared defconfig, so ignore its output and manually
+create CC-list based on MAINTAINERS file or use something like
+``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
Submitting Patches to the Main SoC Maintainers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] Documentation/process: maintainer-soc: Mark 'make' as commands
From: Krzysztof Kozlowski @ 2025-12-23 14:27 UTC (permalink / raw)
To: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20251223142726.73417-3-krzysztof.kozlowski@oss.qualcomm.com>
Improve readability of the docs by marking 'make dtbs/dtbs_check' as
shell commands.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/process/maintainer-soc.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 014c639022b2..7d6bad989ad8 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -116,9 +116,9 @@ coordinating how the changes get merged through different maintainer trees.
Usually the branch that includes a driver change will also include the
corresponding change to the devicetree binding description, to ensure they are
in fact compatible. This means that the devicetree branch can end up causing
-warnings in the "make dtbs_check" step. If a devicetree change depends on
+warnings in the ``make dtbs_check`` step. If a devicetree change depends on
missing additions to a header file in include/dt-bindings/, it will fail the
-"make dtbs" step and not get merged.
+``make dtbs`` step and not get merged.
There are multiple ways to deal with this:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Laurent Pinchart @ 2025-12-23 15:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
In-Reply-To: <20251223142726.73417-3-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
> It is already documented but people still send noticeable amount of
> patches ignoring the rule - get_maintainers.pl does not work on
> arm64/configs/defconfig or any other shared ARM defconfig.
>
> Be more explicit, that one must not rely on typical/simple approach
> here for getting To/Cc list.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> ---
> Documentation/process/maintainer-soc.rst | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> index 3ba886f52a51..014c639022b2 100644
> --- a/Documentation/process/maintainer-soc.rst
> +++ b/Documentation/process/maintainer-soc.rst
> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>
> All typical platform related patches should be sent via SoC submaintainers
> (platform-specific maintainers). This includes also changes to per-platform or
> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> -addresses in such case).
> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> +correct addresses for the shared defconfig, so ignore its output and manually
> +create CC-list based on MAINTAINERS file or use something like
> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
I fear this will be another piece of documentation that people won't
read. It would be more effective to implement custom logic in
get_maintainer.pl (or at least output an informative message).
>
> Submitting Patches to the Main SoC Maintainers
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Jonathan Corbet @ 2025-12-23 15:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20251223142726.73417-3-krzysztof.kozlowski@oss.qualcomm.com>
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:
> It is already documented but people still send noticeable amount of
> patches ignoring the rule - get_maintainers.pl does not work on
> arm64/configs/defconfig or any other shared ARM defconfig.
>
> Be more explicit, that one must not rely on typical/simple approach
> here for getting To/Cc list.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> ---
> Documentation/process/maintainer-soc.rst | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> index 3ba886f52a51..014c639022b2 100644
> --- a/Documentation/process/maintainer-soc.rst
> +++ b/Documentation/process/maintainer-soc.rst
> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>
> All typical platform related patches should be sent via SoC submaintainers
> (platform-specific maintainers). This includes also changes to per-platform or
> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> -addresses in such case).
> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> +correct addresses for the shared defconfig, so ignore its output and manually
> +create CC-list based on MAINTAINERS file or use something like
> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>
Like Laurent, I don't see this as being effective. Why is it that
get_maintainer.pl fails here? It seems far better to fix that, if at
all possible, rather than expect random contributors to notice this text
and work around the problem...?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Krzysztof Kozlowski @ 2025-12-23 15:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
In-Reply-To: <20251223150256.GI9817@pendragon.ideasonboard.com>
On 23/12/2025 16:02, Laurent Pinchart wrote:
> Hi Krzysztof,
>
> On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
>> It is already documented but people still send noticeable amount of
>> patches ignoring the rule - get_maintainers.pl does not work on
>> arm64/configs/defconfig or any other shared ARM defconfig.
>>
>> Be more explicit, that one must not rely on typical/simple approach
>> here for getting To/Cc list.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>> ---
>> Documentation/process/maintainer-soc.rst | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>> index 3ba886f52a51..014c639022b2 100644
>> --- a/Documentation/process/maintainer-soc.rst
>> +++ b/Documentation/process/maintainer-soc.rst
>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>
>> All typical platform related patches should be sent via SoC submaintainers
>> (platform-specific maintainers). This includes also changes to per-platform or
>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>> -addresses in such case).
>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>> +correct addresses for the shared defconfig, so ignore its output and manually
>> +create CC-list based on MAINTAINERS file or use something like
>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>
> I fear this will be another piece of documentation that people won't
> read. It would be more effective to implement custom logic in
> get_maintainer.pl (or at least output an informative message).
Part of the logic is already there, but I will not grow that - I don't
want to touch Perl code. It's pretty obvious the tool should be do it,
so feel free to fix it. No point however to stop proper documentation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Krzysztof Kozlowski @ 2025-12-23 15:36 UTC (permalink / raw)
To: Jonathan Corbet, Arnd Bergmann, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
In-Reply-To: <87ecolxlvk.fsf@trenco.lwn.net>
On 23/12/2025 16:23, Jonathan Corbet wrote:
> Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:
>
>> It is already documented but people still send noticeable amount of
>> patches ignoring the rule - get_maintainers.pl does not work on
>> arm64/configs/defconfig or any other shared ARM defconfig.
>>
>> Be more explicit, that one must not rely on typical/simple approach
>> here for getting To/Cc list.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>> ---
>> Documentation/process/maintainer-soc.rst | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>> index 3ba886f52a51..014c639022b2 100644
>> --- a/Documentation/process/maintainer-soc.rst
>> +++ b/Documentation/process/maintainer-soc.rst
>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>
>> All typical platform related patches should be sent via SoC submaintainers
>> (platform-specific maintainers). This includes also changes to per-platform or
>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>> -addresses in such case).
>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>> +correct addresses for the shared defconfig, so ignore its output and manually
>> +create CC-list based on MAINTAINERS file or use something like
>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>>
>
> Like Laurent, I don't see this as being effective. Why is it that
> get_maintainer.pl fails here? It seems far better to fix that, if at
Because there is no single maintainer for that file but around 60-80,
depending on the context (who owns the CONFIG symbol). We cannot print
all of them and finding actual owner is not a trivial.
> all possible, rather than expect random contributors to notice this text
> and work around the problem...?
Of course better to fix the tool. Problem is known for years (10? 15?).
Was it fixed? No, although in August finally Sebastian Reichel improved
it a bit (See 750b54513f69f1046895346ea97cc3d96584355e) but did not
solve it, because people do not run get_maintainers.pl correctly.
My template reply, so often pasted on mailing lists, always suggest to
use --no-git-fallback, but it's not the default. We could try to make it
default, but it won't solve the problem - output will be empty:
get_maintainer.pl -f --no-git-fallback arch/arm64/configs/defconfig
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Laurent Pinchart @ 2025-12-23 16:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
In-Reply-To: <f858ea0e-24d5-4cdd-ab57-dfeebe67ae7b@oss.qualcomm.com>
On Tue, Dec 23, 2025 at 04:32:02PM +0100, Krzysztof Kozlowski wrote:
> On 23/12/2025 16:02, Laurent Pinchart wrote:
> > On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
> >> It is already documented but people still send noticeable amount of
> >> patches ignoring the rule - get_maintainers.pl does not work on
> >> arm64/configs/defconfig or any other shared ARM defconfig.
> >>
> >> Be more explicit, that one must not rely on typical/simple approach
> >> here for getting To/Cc list.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >>
> >> ---
> >>
> >> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
> >> ---
> >> Documentation/process/maintainer-soc.rst | 6 ++++--
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> >> index 3ba886f52a51..014c639022b2 100644
> >> --- a/Documentation/process/maintainer-soc.rst
> >> +++ b/Documentation/process/maintainer-soc.rst
> >> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
> >>
> >> All typical platform related patches should be sent via SoC submaintainers
> >> (platform-specific maintainers). This includes also changes to per-platform or
> >> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
> >> -addresses in such case).
> >> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
> >> +correct addresses for the shared defconfig, so ignore its output and manually
> >> +create CC-list based on MAINTAINERS file or use something like
> >> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
> >
> > I fear this will be another piece of documentation that people won't
> > read. It would be more effective to implement custom logic in
> > get_maintainer.pl (or at least output an informative message).
>
> Part of the logic is already there, but I will not grow that - I don't
> want to touch Perl code. It's pretty obvious the tool should be do it,
> so feel free to fix it.
Even if I knew perl, I'd have no time :-)
> No point however to stop proper documentation.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Greg Kroah-Hartman @ 2025-12-23 16:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: Kees Cook, Rafael J. Wysocki, Thomas Gleixner, Dave Hansen, dave,
Shuah Khan, Miguel Ojeda, NeilBrown, Lorenzo Stoakes,
Dan Williams, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20251116111732.5159839e@batman.local.home>
On Sun, Nov 16, 2025 at 11:17:32AM -0500, Steven Rostedt wrote:
> On Sun, 16 Nov 2025 07:25:46 -0800
> Kees Cook <kees@kernel.org> wrote:
>
> > A tag isn't going to capture what we need today. Because the LLM
> > usage is so variable, it'll be, at best, misleading or, at worst,
> > totally inaccurate. I've provided several examples of this where the
> > range of LLM involvement is very low to very high. The prior
> > discussions have shown that we haven't yet found a sensible way for a
> > tag to capture that.
> >
> > But the common thing everyone appears to agree on is the "show your
> > work" concept that this patch is trying to capture. I think it's
> > likely we'll grow a tag eventually, but it isn't something we
> > understand the context for yet. As a first step, this document is
> > designed to show the foundational goals for what we want documented.
> >
> > Over some time of applying this, we'll start to see common patterns
> > and repeated descriptions in commit logs. At that point, I think a
> > tag will be warranted. But right now, we don't generally agree about
> > what aspects we want a tag to cover.
>
> Exactly. My fear was that by adding any new rules (like a tag) will
> steer this conversation into a never ending bikeshed arguments, which
> was exactly what we wanted to avoid.
>
> Let's have the "tag" conversation at Maintainers Summit and just keep
> this document as something to describe what we do today.
What's the status of this patch? I don't see it in linux-next, is it
supposed to go through some specific tree?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Jonathan Corbet @ 2025-12-23 17:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, Steven Rostedt
Cc: Kees Cook, Rafael J. Wysocki, Thomas Gleixner, Dave Hansen, dave,
Shuah Khan, Miguel Ojeda, NeilBrown, Lorenzo Stoakes,
Dan Williams, Theodore Ts'o, Sasha Levin, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <2025122358-flyover-tidy-6f4d@gregkh>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> What's the status of this patch? I don't see it in linux-next, is it
> supposed to go through some specific tree?
I've been assuming there would be another version after the meeting, so
haven't applied anything. (Besides, between travel, 100mph winds, and
several days without power, I've not gotten much done in general...)
jon
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2025-12-23 20:56 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg Kroah-Hartman, Kees Cook, Rafael J. Wysocki, Thomas Gleixner,
Dave Hansen, dave, Shuah Khan, Miguel Ojeda, NeilBrown,
Lorenzo Stoakes, Dan Williams, Theodore Ts'o, Sasha Levin,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <87a4z9w2dl.fsf@trenco.lwn.net>
On Tue, 23 Dec 2025 10:10:14 -0700
Jonathan Corbet <corbet@lwn.net> wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>
> > What's the status of this patch? I don't see it in linux-next, is it
> > supposed to go through some specific tree?
>
> I've been assuming there would be another version after the meeting, so
> haven't applied anything. (Besides, between travel, 100mph winds, and
> several days without power, I've not gotten much done in general...)
>
Yeah. I was talking with Dave on the way to the Kill Bill evening event and
I believe he was planning on doing another version sometime when he got back.
Dave correct me if I'm wrong.
-- Steve
^ permalink raw reply
* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Federico Vaga @ 2025-12-23 21:22 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andi Shyti, linux-doc, linux-kernel, workflows, Andy Shevchenko
In-Reply-To: <87bjjq18h6.fsf@trenco.lwn.net>
Hi Jon,
Thank you for your message
On Mon, Dec 22, 2025 at 03:01:57PM -0700, Jonathan Corbet wrote:
>Andi Shyti <andi.shyti@kernel.org> writes:
>
>> Hi Federico,
>>
>>> >-Il file di intestazione include/linux/kernel.h contiene un certo numero
>>> >-di macro che dovreste usare piuttosto che implementarne una qualche variante.
>>> >-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
>>> >-macro:
>>> >+I file header
>>>
>>> In Italian, the correct name for "header file" is "file di intestazione".
>>> Please, don't replace correct Italian with *Itanglese* :)
>>
>> I absolutely disagree.
>>
>> If you open any C book, they are called 'header files', except
>> for a few Italian technical books with excessively literal
>> translations, where even non-translatable terms are translated.
>
>I'm unconvinced about "file di intestazione" based on my own
>understanding of the language... but, in a case like this, I will defer
>to the creator and maintainer of the translation.
Due to my explanation in the previous message, and after your answer, I have the
feeling it may sounds like I'm making up words needing persuasion. Probably I'm
misunderstanding. Just in case, please allow me a clarification.
"File di intestazione" is the equivalent in Italian, same semantic. It can be
found at the university, in books, in youtube videos, and in tutorials about C
and C++ languages. One might have different opinions on the term. But it is a
fact that the term exits, it is Italian, and it is used.
> [...]
> I chose to use Italian terms: (a) when they exist, (b) they have sufficient
> diffusion, and (c) if it adds value for a wider audience.
> [...]
A short list of references.
Universities:
Napoli: https://www.docenti.unina.it/webdocenti-be/allegati/materiale-didattico/94515
Bologna: http://lia.deis.unibo.it/Courses/FondA0607-ELE/materiale/Lucidi/ProgettiSuPiuFile.pdf
Milano: https://aguzzoli.di.unimi.it/didattica/algo12/lucidi1.pdf
Torino: https://staff.polito.it/claudio.fornaro/CorsoC/09-Stringhe.pdf
Wikis:
https://it.wikibooks.org/wiki/Dal_C_al_C++/Utilizzo_basilare_di_librerie/I_file_di_intestazione
https://it.wikibooks.org/wiki/C/Compilatore_e_precompilatore/Header
https://it.wikipedia.org/wiki/Direttiva_di_inclusione
From Italian-aware automatic translations:
https://www.ibm.com/docs/it/aix/7.3.0?topic=reference-header-files
https://learn.microsoft.com/it-it/cpp/cpp/header-files-cpp
Books:
Original Italian:
https://www.google.ch/books/edition/Dalla_A_alla_Z_passando_per_C/OXoFAgAAQBAJ?hl=it&gbpv=0
Translated from English:
https://www.google.ch/books/edition/C++_Fondamenti_di_programmazione/fPaLAwAAQBAJ?hl=it&gbpv=0
Another source from the GNU/Linux world:
PLUTO (Appunti di informatica libera):
http://a2.pluto.it/a292.htm#almltitle3828
--
Federico Vaga
^ permalink raw reply
* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Jonathan Corbet @ 2025-12-23 21:34 UTC (permalink / raw)
To: Federico Vaga
Cc: Andi Shyti, linux-doc, linux-kernel, workflows, Andy Shevchenko
In-Reply-To: <b5niunhlqabuekgmsf4xrhqntx6qwi44mh7smntocomfjhoadk@fazjt4uqiv4w>
Federico Vaga <federico.vaga@vaga.pv.it> writes:
>>I'm unconvinced about "file di intestazione" based on my own
>>understanding of the language... but, in a case like this, I will defer
>>to the creator and maintainer of the translation.
>
> Due to my explanation in the previous message, and after your answer,
> I have the feeling it may sounds like I'm making up words needing
> persuasion. Probably I'm misunderstanding. Just in case, please allow
> me a clarification.
No, that was not my intent at all. It's a term I haven't encountered
before, but that doesn't mean you made it up :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/process: maintainer-soc: Be more explicit about defconfig
From: Krzysztof Kozlowski @ 2025-12-24 8:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, linux-arm-kernel,
soc, workflows, linux-doc, linux-kernel
In-Reply-To: <20251223162756.GA25011@pendragon.ideasonboard.com>
On 23/12/2025 17:27, Laurent Pinchart wrote:
> On Tue, Dec 23, 2025 at 04:32:02PM +0100, Krzysztof Kozlowski wrote:
>> On 23/12/2025 16:02, Laurent Pinchart wrote:
>>> On Tue, Dec 23, 2025 at 03:27:27PM +0100, Krzysztof Kozlowski wrote:
>>>> It is already documented but people still send noticeable amount of
>>>> patches ignoring the rule - get_maintainers.pl does not work on
>>>> arm64/configs/defconfig or any other shared ARM defconfig.
>>>>
>>>> Be more explicit, that one must not rely on typical/simple approach
>>>> here for getting To/Cc list.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>
>>>> ---
>>>>
>>>> Incorrectly addressed patches for arm64/defconfig are around ~2 per month...
>>>> ---
>>>> Documentation/process/maintainer-soc.rst | 6 ++++--
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
>>>> index 3ba886f52a51..014c639022b2 100644
>>>> --- a/Documentation/process/maintainer-soc.rst
>>>> +++ b/Documentation/process/maintainer-soc.rst
>>>> @@ -57,8 +57,10 @@ Submitting Patches for Given SoC
>>>>
>>>> All typical platform related patches should be sent via SoC submaintainers
>>>> (platform-specific maintainers). This includes also changes to per-platform or
>>>> -shared defconfigs (scripts/get_maintainer.pl might not provide correct
>>>> -addresses in such case).
>>>> +shared defconfigs. Note that scripts/get_maintainer.pl might not provide
>>>> +correct addresses for the shared defconfig, so ignore its output and manually
>>>> +create CC-list based on MAINTAINERS file or use something like
>>>> +``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
>>>
>>> I fear this will be another piece of documentation that people won't
>>> read. It would be more effective to implement custom logic in
>>> get_maintainer.pl (or at least output an informative message).
>>
>> Part of the logic is already there, but I will not grow that - I don't
>> want to touch Perl code. It's pretty obvious the tool should be do it,
>> so feel free to fix it.
>
> Even if I knew perl, I'd have no time :-)
Same here. I see little incentive for me to spend significant amount of
time on this - considering I barely know Perl and how much I like this
language - to solve not my problem. The best I could do is to clarify
the docs. I agree however that this will be one more ignored doc, so I
don't mind skipping the patch.
Patch 2/2 is independent though, so please still consider it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2025-12-24 15:41 UTC (permalink / raw)
To: Steven Rostedt, Jonathan Corbet
Cc: Greg Kroah-Hartman, Kees Cook, Rafael J. Wysocki, Thomas Gleixner,
Dave Hansen, Shuah Khan, Miguel Ojeda, NeilBrown, Lorenzo Stoakes,
Dan Williams, Theodore Ts'o, Sasha Levin, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20251223155652.7c52630e@gandalf.local.home>
On 12/23/25 12:56, Steven Rostedt wrote:
>>> What's the status of this patch? I don't see it in linux-next, is it
>>> supposed to go through some specific tree?
>> I've been assuming there would be another version after the meeting, so
>> haven't applied anything. (Besides, between travel, 100mph winds, and
>> several days without power, I've not gotten much done in general...)
>>
> Yeah. I was talking with Dave on the way to the Kill Bill evening event and
> I believe he was planning on doing another version sometime when he got back.
>
> Dave correct me if I'm wrong.
Yup, I was just waiting to post again until I know I can be attentive to
email and responsive to an reviewers. It's definitely not dropped on the
floor.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Simon Glass @ 2025-12-24 16:23 UTC (permalink / raw)
To: Dave Hansen
Cc: Steven Rostedt, Jonathan Corbet, Greg Kroah-Hartman, Kees Cook,
Rafael J. Wysocki, Thomas Gleixner, Dave Hansen, Shuah Khan,
Miguel Ojeda, NeilBrown, Lorenzo Stoakes, Dan Williams,
Theodore Ts'o, Sasha Levin, Vlastimil Babka, workflows,
ksummit
In-Reply-To: <d0903ed7-e2db-4d8c-ab7f-0beb84760f07@sr71.net>
On Wed, 24 Dec 2025 at 08:47, Dave Hansen <dave@sr71.net> wrote:
>
> On 12/23/25 12:56, Steven Rostedt wrote:
> >>> What's the status of this patch? I don't see it in linux-next, is it
> >>> supposed to go through some specific tree?
> >> I've been assuming there would be another version after the meeting, so
> >> haven't applied anything. (Besides, between travel, 100mph winds, and
> >> several days without power, I've not gotten much done in general...)
> >>
> > Yeah. I was talking with Dave on the way to the Kill Bill evening event and
> > I believe he was planning on doing another version sometime when he got back.
> >
> > Dave correct me if I'm wrong.
>
> Yup, I was just waiting to post again until I know I can be attentive to
> email and responsive to an reviewers. It's definitely not dropped on the
> floor.
>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
^ permalink raw reply
* [PATCH] docs: submitting-patches: suggest adding previous version links
From: SeongJae Park @ 2025-12-25 1:54 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: SeongJae Park, linux-doc, linux-kernel, workflows
For review of patches that revisioned multiple times, patch changelogs
are very useful. Adding actual links to the previous versions can
further help the review. Using such links, reviewers can double check
the changelog by themselves, and find previous discussions. Nowadays
having such links (e.g., lore.kernel.org archive links) is easy and
reliable. Suggest adding such links if available.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/process/submitting-patches.rst | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 9a509f1a6873..e69d19ad658f 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -805,7 +805,8 @@ not part of the changelog which gets committed to the git tree. It is
additional information for the reviewers. If it's placed above the
commit tags, it needs manual interaction to remove it. If it is below
the separator line, it gets automatically stripped off when applying the
-patch::
+patch. If available, adding links to previous versions of the patch (e.g.,
+lore.kernel.org archive link) is recommended to help reviewers::
<commit message>
...
@@ -814,6 +815,9 @@ patch::
V2 -> V3: Removed redundant helper function
V1 -> V2: Cleaned up coding style and addressed review comments
+ v2: https://lore.kernel.org/bar
+ v1: https://lore.kernel.org/foo
+
path/to/file | 5+++--
...
base-commit: 7f3c3a0a9103dc92c823f27db3284ac2914e7558
--
2.47.3
^ permalink raw reply related
* [PATCH] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Vincent Mailhol @ 2025-12-25 12:32 UTC (permalink / raw)
To: Jonathan Corbet
Cc: workflows, linux-doc, linux-kernel, Rob Landley, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade, Randy Dunlap,
Vincent Mailhol
While reading the git-format-patch manpages [1], I discovered the existence
of the "Toggle Line Wrap" extension for Thunderbird which I found rather
convenient.
Looking at the history, the ancestor of this extension was added to the
documentation in commit e0e34e977a7c ("Documentation/email-clients.txt:
update Thunderbird docs with wordwrap plugin") but then removed in commit
f9a0974d3f70 ("Documentation: update thunderbird email client settings").
Extend the paragraph on Thunderbird's mailnews.wraplength register to
mention the existence of the "Toggle Line Wrap" extension. The goal is not
to create a war on what is the best option so make it clear that this is an
alternative.
[1] man git-format-patch -- §Thunderbird
Link: https://git-scm.com/docs/git-format-patch#_thunderbird
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
and Merry Christmas!
---
Documentation/process/email-clients.rst | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst
index 84a2450bb6ec..27cd43b185dd 100644
--- a/Documentation/process/email-clients.rst
+++ b/Documentation/process/email-clients.rst
@@ -324,7 +324,14 @@ To beat some sense out of the internal editor, do this:
- Set ``mailnews.send_plaintext_flowed`` to ``false``
- - Set ``mailnews.wraplength`` from ``72`` to ``0``
+ - Set ``mailnews.wraplength`` from ``72`` to ``0`` **or** install the
+ "Toggle Line Wrap" extension
+
+ https://github.com/jan-kiszka/togglelinewrap
+
+ https://addons.thunderbird.net/fr/thunderbird/addon/toggle-line-wrap/
+
+ to control this registry on the fly.
- Don't write HTML messages! Go to the main window
:menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`!
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251225-docs_thunderbird-toggle-line-wrap-dbe39bcb650b
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
^ permalink raw reply related
* [PATCH] Doc: correct spelling and wording mistakes
From: Volodymyr Kot @ 2025-12-25 13:39 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, linux-kernel, Volodymyr Kot
Fixed capitalization and punctuation in process documentation.
Signed-off-by: Volodymyr Kot <volodymyr.kot.ua@gmail.com>
---
Documentation/process/1.Intro.rst | 2 +-
Documentation/process/2.Process.rst | 2 +-
Documentation/process/4.Coding.rst | 6 +++---
Documentation/process/7.AdvancedTopics.rst | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/process/1.Intro.rst b/Documentation/process/1.Intro.rst
index 25ca49f7ae4d..2c93caea069f 100644
--- a/Documentation/process/1.Intro.rst
+++ b/Documentation/process/1.Intro.rst
@@ -194,7 +194,7 @@ include:
are cloudy at best; quite a few kernel copyright holders believe that
most binary-only modules are derived products of the kernel and that, as
a result, their distribution is a violation of the GNU General Public
- license (about which more will be said below). Your author is not a
+ License (about which more will be said below). Your author is not a
lawyer, and nothing in this document can possibly be considered to be
legal advice. The true legal status of closed-source modules can only be
determined by the courts. But the uncertainty which haunts those modules
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index 7bd41838a546..57fa8cac58a6 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -3,7 +3,7 @@
How the development process works
=================================
-Linux kernel development in the early 1990's was a pretty loose affair,
+Linux kernel development in the early 1990s was a pretty loose affair,
with relatively small numbers of users and developers involved. With a
user base in the millions and with some 2,000 developers involved over the
course of one year, the kernel has since had to evolve a number of
diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst
index 80bcc1cabc23..c0f57d0c4f73 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -160,12 +160,12 @@ irrelevant.
Locking
*******
-In May, 2006, the "Devicescape" networking stack was, with great
+In May 2006, the "Devicescape" networking stack was, with great
fanfare, released under the GPL and made available for inclusion in the
mainline kernel. This donation was welcome news; support for wireless
networking in Linux was considered substandard at best, and the Devicescape
stack offered the promise of fixing that situation. Yet, this code did not
-actually make it into the mainline until June, 2007 (2.6.22). What
+actually make it into the mainline until June 2007 (2.6.22). What
happened?
This code showed a number of signs of having been developed behind
@@ -204,7 +204,7 @@ regression in the first place.
It is often argued that a regression can be justified if it causes things
to work for more people than it creates problems for. Why not make a
change if it brings new functionality to ten systems for each one it
-breaks? The best answer to this question was expressed by Linus in July,
+breaks? The best answer to this question was expressed by Linus in July
2007:
::
diff --git a/Documentation/process/7.AdvancedTopics.rst b/Documentation/process/7.AdvancedTopics.rst
index 43291704338e..185651d87f2a 100644
--- a/Documentation/process/7.AdvancedTopics.rst
+++ b/Documentation/process/7.AdvancedTopics.rst
@@ -53,7 +53,7 @@ When you are ready to start putting up git trees for others to look at, you
will, of course, need a server that can be pulled from. Setting up such a
server with git-daemon is relatively straightforward if you have a system
which is accessible to the Internet. Otherwise, free, public hosting sites
-(Github, for example) are starting to appear on the net. Established
+(GitHub, for example) are starting to appear on the net. Established
developers can get an account on kernel.org, but those are not easy to come
by; see https://kernel.org/faq/ for more information.
--
2.51.2
^ permalink raw reply related
* Re: [PATCH] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Randy Dunlap @ 2025-12-25 20:41 UTC (permalink / raw)
To: Vincent Mailhol, Jonathan Corbet
Cc: workflows, linux-doc, linux-kernel, Rob Landley, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade
In-Reply-To: <20251225-docs_thunderbird-toggle-line-wrap-v1-1-24794afa4abf@kernel.org>
Hi,
On 12/25/25 4:32 AM, Vincent Mailhol wrote:
> While reading the git-format-patch manpages [1], I discovered the existence
> of the "Toggle Line Wrap" extension for Thunderbird which I found rather
> convenient.
>
> Looking at the history, the ancestor of this extension was added to the
> documentation in commit e0e34e977a7c ("Documentation/email-clients.txt:
> update Thunderbird docs with wordwrap plugin") but then removed in commit
> f9a0974d3f70 ("Documentation: update thunderbird email client settings").
>
> Extend the paragraph on Thunderbird's mailnews.wraplength register to
> mention the existence of the "Toggle Line Wrap" extension. The goal is not
> to create a war on what is the best option so make it clear that this is an
> alternative.
>
> [1] man git-format-patch -- §Thunderbird
> Link: https://git-scm.com/docs/git-format-patch#_thunderbird
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> and Merry Christmas!
> ---
> Documentation/process/email-clients.rst | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst
> index 84a2450bb6ec..27cd43b185dd 100644
> --- a/Documentation/process/email-clients.rst
> +++ b/Documentation/process/email-clients.rst
> @@ -324,7 +324,14 @@ To beat some sense out of the internal editor, do this:
>
> - Set ``mailnews.send_plaintext_flowed`` to ``false``
>
> - - Set ``mailnews.wraplength`` from ``72`` to ``0``
> + - Set ``mailnews.wraplength`` from ``72`` to ``0`` **or** install the
> + "Toggle Line Wrap" extension
> +
> + https://github.com/jan-kiszka/togglelinewrap
> +
> + https://addons.thunderbird.net/fr/thunderbird/addon/toggle-line-wrap/
Please use the URL from the git-scm.com web page (i.e., without "fr/").
https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
> +
> + to control this registry on the fly.
>
> - Don't write HTML messages! Go to the main window
> :menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`!
>
> ---
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> change-id: 20251225-docs_thunderbird-toggle-line-wrap-dbe39bcb650b
>
> Best regards,
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Vincent Mailhol @ 2025-12-25 23:35 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Corbet
Cc: workflows, linux-doc, linux-kernel, Rob Landley, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade
In-Reply-To: <1aba733a-b29a-4931-b1c9-7df35774db38@infradead.org>
On 25/12/2025 at 21:41, Randy Dunlap wrote:
> Hi,
>
> On 12/25/25 4:32 AM, Vincent Mailhol wrote:
(...)
>> + https://addons.thunderbird.net/fr/thunderbird/addon/toggle-line-wrap/
>
> Please use the URL from the git-scm.com web page (i.e., without "fr/").
>
> https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
D'oh, I didn't realize that I was pointing to the French page. Thanks
for spotting that!
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* [PATCH v2] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Vincent Mailhol @ 2025-12-25 23:46 UTC (permalink / raw)
To: Jonathan Corbet
Cc: workflows, linux-doc, linux-kernel, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade, Jan Kiszka,
Randy Dunlap, Vincent Mailhol
While reading the git-format-patch manpages [1], I discovered the existence
of the "Toggle Line Wrap" extension for Thunderbird which I found rather
convenient.
Looking at the history, the ancestor of this extension was added to the
documentation in commit e0e34e977a7c ("Documentation/email-clients.txt:
update Thunderbird docs with wordwrap plugin") but then removed in commit
f9a0974d3f70 ("Documentation: update thunderbird email client settings").
Extend the paragraph on Thunderbird's mailnews.wraplength register to
mention the existence of the "Toggle Line Wrap" extension. The goal is not
to create a war on what is the best option so make it clear that this is
just an alternative.
[1] man git-format-patch -- §Thunderbird
Link: https://git-scm.com/docs/git-format-patch#_thunderbird
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Changes in v2:
- Use the international URL (remove "fr/")
Link to v1: https://lore.kernel.org/r/20251225-docs_thunderbird-toggle-line-wrap-v1-1-24794afa4abf@kernel.org
---
Documentation/process/email-clients.rst | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst
index 84a2450bb6ec..b5377630a648 100644
--- a/Documentation/process/email-clients.rst
+++ b/Documentation/process/email-clients.rst
@@ -324,7 +324,14 @@ To beat some sense out of the internal editor, do this:
- Set ``mailnews.send_plaintext_flowed`` to ``false``
- - Set ``mailnews.wraplength`` from ``72`` to ``0``
+ - Set ``mailnews.wraplength`` from ``72`` to ``0`` **or** install the
+ "Toggle Line Wrap" extension
+
+ https://github.com/jan-kiszka/togglelinewrap
+
+ https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
+
+ to control this registry on the fly.
- Don't write HTML messages! Go to the main window
:menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`!
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251225-docs_thunderbird-toggle-line-wrap-dbe39bcb650b
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Randy Dunlap @ 2025-12-26 2:11 UTC (permalink / raw)
To: Vincent Mailhol, Jonathan Corbet
Cc: workflows, linux-doc, linux-kernel, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade, Jan Kiszka
In-Reply-To: <20251226-docs_thunderbird-toggle-line-wrap-v2-1-aebb8c60025d@kernel.org>
On 12/25/25 3:46 PM, Vincent Mailhol wrote:
> While reading the git-format-patch manpages [1], I discovered the existence
> of the "Toggle Line Wrap" extension for Thunderbird which I found rather
> convenient.
>
> Looking at the history, the ancestor of this extension was added to the
> documentation in commit e0e34e977a7c ("Documentation/email-clients.txt:
> update Thunderbird docs with wordwrap plugin") but then removed in commit
> f9a0974d3f70 ("Documentation: update thunderbird email client settings").
>
> Extend the paragraph on Thunderbird's mailnews.wraplength register to
> mention the existence of the "Toggle Line Wrap" extension. The goal is not
> to create a war on what is the best option so make it clear that this is
> just an alternative.
>
> [1] man git-format-patch -- §Thunderbird
> Link: https://git-scm.com/docs/git-format-patch#_thunderbird
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Changes in v2:
>
> - Use the international URL (remove "fr/")
>
> Link to v1: https://lore.kernel.org/r/20251225-docs_thunderbird-toggle-line-wrap-v1-1-24794afa4abf@kernel.org
> ---
> Documentation/process/email-clients.rst | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst
> index 84a2450bb6ec..b5377630a648 100644
> --- a/Documentation/process/email-clients.rst
> +++ b/Documentation/process/email-clients.rst
> @@ -324,7 +324,14 @@ To beat some sense out of the internal editor, do this:
>
> - Set ``mailnews.send_plaintext_flowed`` to ``false``
>
> - - Set ``mailnews.wraplength`` from ``72`` to ``0``
> + - Set ``mailnews.wraplength`` from ``72`` to ``0`` **or** install the
> + "Toggle Line Wrap" extension
> +
> + https://github.com/jan-kiszka/togglelinewrap
> +
> + https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
> +
> + to control this registry on the fly.
>
> - Don't write HTML messages! Go to the main window
> :menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`!
>
> ---
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> change-id: 20251225-docs_thunderbird-toggle-line-wrap-dbe39bcb650b
>
> Best regards,
--
~Randy
^ permalink raw reply
* Re: [PATCH 6/9] CodingStyle: recommend static_assert/_Static_assert
From: Alexey Dobriyan @ 2025-12-27 14:51 UTC (permalink / raw)
To: David Laight; +Cc: corbet, workflows, linux-kernel
In-Reply-To: <20250513204031.26f50209@pumpkin>
On Tue, May 13, 2025 at 08:40:31PM +0100, David Laight wrote:
> On Fri, 9 May 2025 23:34:27 +0300
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> > Linux's BUG_ON is done backwards (condition is inverted).
> > But it is a long story.
> >
> > However C11/C23 allow to partially transition to what all normal
> > programmers are used to, namely assert().
> >
> > Deprecate BUILD_BUG_ON, recommend static_assert/_Static_assert.
> > And then some day BUG_ON will be flipped as well.
>
> _Static_assert() is broken by design and only usable for trival tests.
It is not broken by design. I was going to recommend it
for "static_assert(sizeof(struct S) == ...)" type of things. For ABI types and
similar stuff.
BTW BUILD_BUG_ON is broken by design too, there are places with fake functions
for a block so that they can put statement in.
> clang also output the entire expansion of the conditional (even when
> a message is specified) which can lead to very very very very long lines.
Oh, that's very unfortunate.
> It isn't at all suitable for many of the checks in the kernel.
STATIC_ASSERT could be arranged.
> Look at the signedness test in min() as an example.
The very fact you all made giant mess trying to imitate min<T, U>()
should not block progress of using standard (and better!) stuff.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox