* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <9e0b0711-b558-4f58-9f6a-3463cbc50669@infradead.org>
On Wed, Nov 26, 2025 at 01:36:44PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:33 PM, Randy Dunlap wrote:
> > On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> >> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> >>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> >>>> -The header file include/linux/kernel.h contains a number of macros that
> >>>> +There many header files in include/linux/ that contain a number of macros that
> >>>
> >>> There are many
> >>>
> >>>> you should use, rather than explicitly coding some variant of them yourself.
> >>>> For example, if you need to calculate the length of an array, take advantage
> >>>> of the macro
> >>>
> >>> Otherwise LGTM. Thanks.
> >>>
> >>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Thanks!
> >>
> >> Can you also test it? I hope it will be not so broken (as some of the files
> >> seems never were before in the generated docs).
> >
> > It's not completely happy:
> >
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
> >
>
> This little change fixes it for me. Just include it in your patch, please.
Thanks, just 15 sec before your message I guessed the same fix.
> ---
> include/linux/util_macros.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20251126.orig/include/linux/util_macros.h
> +++ linux-next-20251126/include/linux/util_macros.h
> @@ -119,7 +119,7 @@
> * a fuss about it. This makes the programmer responsible for tagging
> * the functions that can be garbage-collected.
> *
> - * With the macro it is possible to write the following:
> + * With the macro it is possible to write the following::
> *
> * static int foo_suspend(struct device *dev)
> * {
Since it's like this, I just fix both places you pointed out and issue a v2.
May I have ypour Tested-by ten?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzo8aOns_3oPQA@smile.fi.intel.com>
On 11/26/25 1:39 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 11:37:40PM +0200, Andy Shevchenko wrote:
>> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
>>> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>>>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>>>> +There many header files in include/linux/ that contain a number of macros that
>>>>>
>>>>> There are many
>>>>>
>>>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>>>> For example, if you need to calculate the length of an array, take advantage
>>>>>> of the macro
>>>>>
>>>>> Otherwise LGTM. Thanks.
>>>>>
>>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>>>
>>>> Thanks!
>>>>
>>>> Can you also test it? I hope it will be not so broken (as some of the files
>>>> seems never were before in the generated docs).
>>>
>>> It's not completely happy:
>>
>> A-ha, thanks for trying!
>>
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>>
>>
>> I will look at it tomorrow, but can you remove this (or even fix) and check the
>> rest meanwhile?
>
> At glance seems like colon is missing, should be :: instead of : in near lines.
>
Yes, that's what I sent earlier :)
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:39 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzHqxI-iDsksao@smile.fi.intel.com>
On Wed, Nov 26, 2025 at 11:37:40PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
> > On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> > > On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> > >> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> > >>> -The header file include/linux/kernel.h contains a number of macros that
> > >>> +There many header files in include/linux/ that contain a number of macros that
> > >>
> > >> There are many
> > >>
> > >>> you should use, rather than explicitly coding some variant of them yourself.
> > >>> For example, if you need to calculate the length of an array, take advantage
> > >>> of the macro
> > >>
> > >> Otherwise LGTM. Thanks.
> > >>
> > >> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> > >
> > > Thanks!
> > >
> > > Can you also test it? I hope it will be not so broken (as some of the files
> > > seems never were before in the generated docs).
> >
> > It's not completely happy:
>
> A-ha, thanks for trying!
>
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> > linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
> I will look at it tomorrow, but can you remove this (or even fix) and check the
> rest meanwhile?
At glance seems like colon is missing, should be :: instead of : in near lines.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdzHqxI-iDsksao@smile.fi.intel.com>
On 11/26/25 1:37 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
>> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>>> +There many header files in include/linux/ that contain a number of macros that
>>>>
>>>> There are many
>>>>
>>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>>> For example, if you need to calculate the length of an array, take advantage
>>>>> of the macro
>>>>
>>>> Otherwise LGTM. Thanks.
>>>>
>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>>
>>> Thanks!
>>>
>>> Can you also test it? I hope it will be not so broken (as some of the files
>>> seems never were before in the generated docs).
>>
>> It's not completely happy:
>
> A-ha, thanks for trying!
>
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
> I will look at it tomorrow, but can you remove this (or even fix) and check the
> rest meanwhile?
That was the only docs warnings caused by your patch (at least in my testing).
and now easily fixed.
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:37 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <8d68b0b7-ee9e-4121-aa85-19fbf8470fdc@infradead.org>
On Wed, Nov 26, 2025 at 01:33:13PM -0800, Randy Dunlap wrote:
> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> > On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> >> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> >>> -The header file include/linux/kernel.h contains a number of macros that
> >>> +There many header files in include/linux/ that contain a number of macros that
> >>
> >> There are many
> >>
> >>> you should use, rather than explicitly coding some variant of them yourself.
> >>> For example, if you need to calculate the length of an array, take advantage
> >>> of the macro
> >>
> >> Otherwise LGTM. Thanks.
> >>
> >> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> >
> > Thanks!
> >
> > Can you also test it? I hope it will be not so broken (as some of the files
> > seems never were before in the generated docs).
>
> It's not completely happy:
A-ha, thanks for trying!
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
I will look at it tomorrow, but can you remove this (or even fix) and check the
rest meanwhile?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <8d68b0b7-ee9e-4121-aa85-19fbf8470fdc@infradead.org>
On 11/26/25 1:33 PM, Randy Dunlap wrote:
>
>
> On 11/26/25 1:24 PM, Andy Shevchenko wrote:
>> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>>
>> ...
>>
>>>> -The header file include/linux/kernel.h contains a number of macros that
>>>> +There many header files in include/linux/ that contain a number of macros that
>>>
>>> There are many
>>>
>>>> you should use, rather than explicitly coding some variant of them yourself.
>>>> For example, if you need to calculate the length of an array, take advantage
>>>> of the macro
>>>
>>> Otherwise LGTM. Thanks.
>>>
>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>
>> Thanks!
>>
>> Can you also test it? I hope it will be not so broken (as some of the files
>> seems never were before in the generated docs).
>
> It's not completely happy:
>
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
> linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
>
>
This little change fixes it for me. Just include it in your patch, please.
---
include/linux/util_macros.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20251126.orig/include/linux/util_macros.h
+++ linux-next-20251126/include/linux/util_macros.h
@@ -119,7 +119,7 @@
* a fuss about it. This makes the programmer responsible for tagging
* the functions that can be garbage-collected.
*
- * With the macro it is possible to write the following:
+ * With the macro it is possible to write the following::
*
* static int foo_suspend(struct device *dev)
* {
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <aSdwIN6qA-66hYhm@smile.fi.intel.com>
On 11/26/25 1:24 PM, Andy Shevchenko wrote:
> On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
>> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
>
> ...
>
>>> -The header file include/linux/kernel.h contains a number of macros that
>>> +There many header files in include/linux/ that contain a number of macros that
>>
>> There are many
>>
>>> you should use, rather than explicitly coding some variant of them yourself.
>>> For example, if you need to calculate the length of an array, take advantage
>>> of the macro
>>
>> Otherwise LGTM. Thanks.
>>
>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks!
>
> Can you also test it? I hope it will be not so broken (as some of the files
> seems never were before in the generated docs).
It's not completely happy:
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:125: ERROR: Unexpected indentation. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:123: WARNING: Inline emphasis start-string without end-string. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:126: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
linux-next-20251126/Documentation/driver-api/basics:130: ../include/linux/util_macros.h:130: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils]
--
~Randy
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 21:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn,
Joe Perches, Bjorn Andersson, Mathieu Poirier
In-Reply-To: <e5ca4be6-6919-4855-bb7f-bd36761eab0f@infradead.org>
On Wed, Nov 26, 2025 at 01:18:29PM -0800, Randy Dunlap wrote:
> On 11/26/25 12:59 PM, Andy Shevchenko wrote:
...
> > -The header file include/linux/kernel.h contains a number of macros that
> > +There many header files in include/linux/ that contain a number of macros that
>
> There are many
>
> > you should use, rather than explicitly coding some variant of them yourself.
> > For example, if you need to calculate the length of an array, take advantage
> > of the macro
>
> Otherwise LGTM. Thanks.
>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks!
Can you also test it? I hope it will be not so broken (as some of the files
seems never were before in the generated docs).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Randy Dunlap @ 2025-11-26 21:18 UTC (permalink / raw)
To: Andy Shevchenko, Dr. David Alan Gilbert, linux-doc, linux-kernel,
workflows, linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Bjorn Andersson, Mathieu Poirier
In-Reply-To: <20251126205939.2321498-1-andriy.shevchenko@linux.intel.com>
On 11/26/25 12:59 PM, Andy Shevchenko wrote:
> For several years, and still ongoing, the kernel.h is being split
> to smaller and narrow headers to avoid "including everything" approach
> which is bad in many ways. Since that, documentation missed a few
> required updates to align with that work. Do it here.
>
> Note, language translations are left untouched and if anybody willing
> to help, please provide path(es) based on the updated English variant.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> Documentation/core-api/kobject.rst | 2 +-
> Documentation/dev-tools/checkpatch.rst | 2 +-
> Documentation/driver-api/basics.rst | 17 ++++++++++++++++-
> .../driver-api/driver-model/design-patterns.rst | 2 +-
> Documentation/process/coding-style.rst | 10 +++++++---
> Documentation/staging/rpmsg.rst | 7 +++++--
> 6 files changed, 31 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 2969ca378dbb..d63ea0bffdfe 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -1070,7 +1070,7 @@ readability.
> 18) Don't re-invent the kernel macros
> -------------------------------------
>
> -The header file include/linux/kernel.h contains a number of macros that
> +There many header files in include/linux/ that contain a number of macros that
There are many
> you should use, rather than explicitly coding some variant of them yourself.
> For example, if you need to calculate the length of an array, take advantage
> of the macro
Otherwise LGTM. Thanks.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* [PATCH v1 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Andy Shevchenko @ 2025-11-26 20:59 UTC (permalink / raw)
To: Andy Shevchenko, Dr. David Alan Gilbert, linux-doc, linux-kernel,
workflows, linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Bjorn Andersson, Mathieu Poirier
For several years, and still ongoing, the kernel.h is being split
to smaller and narrow headers to avoid "including everything" approach
which is bad in many ways. Since that, documentation missed a few
required updates to align with that work. Do it here.
Note, language translations are left untouched and if anybody willing
to help, please provide path(es) based on the updated English variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Documentation/core-api/kobject.rst | 2 +-
Documentation/dev-tools/checkpatch.rst | 2 +-
Documentation/driver-api/basics.rst | 17 ++++++++++++++++-
.../driver-api/driver-model/design-patterns.rst | 2 +-
Documentation/process/coding-style.rst | 10 +++++++---
Documentation/staging/rpmsg.rst | 7 +++++--
6 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/Documentation/core-api/kobject.rst b/Documentation/core-api/kobject.rst
index 7310247310a0..5f6c61bc03bf 100644
--- a/Documentation/core-api/kobject.rst
+++ b/Documentation/core-api/kobject.rst
@@ -78,7 +78,7 @@ just a matter of using the kobj member. Code that works with kobjects will
often have the opposite problem, however: given a struct kobject pointer,
what is the pointer to the containing structure? You must avoid tricks
(such as assuming that the kobject is at the beginning of the structure)
-and, instead, use the container_of() macro, found in ``<linux/kernel.h>``::
+and, instead, use the container_of() macro, found in ``<linux/container_of.h>``::
container_of(ptr, type, member)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index fa2988dd4657..c1dff8e6bccb 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -753,7 +753,7 @@ Macros, Attributes and Symbols
sizeof(foo)/sizeof(foo[0]) for finding number of elements in an
array.
- The macro is defined in include/linux/kernel.h::
+ The macro is defined in include/linux/array_size.h::
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index 5e9f7aee71a7..8b6a5888cb11 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -114,10 +114,25 @@ Kernel objects manipulation
Kernel utility functions
------------------------
-.. kernel-doc:: include/linux/kernel.h
+.. kernel-doc:: include/linux/array_size.h
+ :internal:
+
+.. kernel-doc:: include/linux/container_of.h
+ :internal:
+
+.. kernel-doc:: include/linux/kstrtox.h
:internal:
:no-identifiers: kstrtol kstrtoul
+.. kernel-doc:: include/linux/stddef.h
+ :internal:
+
+.. kernel-doc:: include/linux/util_macros.h
+ :internal:
+
+.. kernel-doc:: include/linux/wordpart.h
+ :internal:
+
.. kernel-doc:: kernel/printk/printk.c
:export:
:no-identifiers: printk
diff --git a/Documentation/driver-api/driver-model/design-patterns.rst b/Documentation/driver-api/driver-model/design-patterns.rst
index 41eb8f41f7dd..965b2b93be6f 100644
--- a/Documentation/driver-api/driver-model/design-patterns.rst
+++ b/Documentation/driver-api/driver-model/design-patterns.rst
@@ -103,7 +103,7 @@ The design pattern is the same for an hrtimer or something similar that will
return a single argument which is a pointer to a struct member in the
callback.
-container_of() is a macro defined in <linux/kernel.h>
+container_of() is a macro defined in <linux/container_of.h>
What container_of() does is to obtain a pointer to the containing struct from
a pointer to a member by a simple subtraction using the offsetof() macro from
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2969ca378dbb..d63ea0bffdfe 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -1070,7 +1070,7 @@ readability.
18) Don't re-invent the kernel macros
-------------------------------------
-The header file include/linux/kernel.h contains a number of macros that
+There many header files in include/linux/ that contain a number of macros that
you should use, rather than explicitly coding some variant of them yourself.
For example, if you need to calculate the length of an array, take advantage
of the macro
@@ -1079,14 +1079,18 @@ of the macro
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+which is defined in array_size.h.
+
Similarly, if you need to calculate the size of some structure member, use
.. code-block:: c
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
-There are also min() and max() macros that do strict type checking if you
-need them. Feel free to peruse that header file to see what else is already
+which is defined in stddef.h.
+
+There are also min() and max() macros defined in minmax.h that do strict type checking if you
+need them. Feel free to peruse the header files to see what else is already
defined that you shouldn't reproduce in your code.
diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst
index 40282cca86ca..42bac1149d9d 100644
--- a/Documentation/staging/rpmsg.rst
+++ b/Documentation/staging/rpmsg.rst
@@ -224,9 +224,12 @@ content to the console.
::
- #include <linux/kernel.h>
+ #include <linux/dev_printk.h>
+ #include <linux/mod_devicetable.h>
#include <linux/module.h>
+ #include <linux/printk.h>
#include <linux/rpmsg.h>
+ #include <linux/types.h>
static void rpmsg_sample_cb(struct rpmsg_channel *rpdev, void *data, int len,
void *priv, u32 src)
@@ -244,7 +247,7 @@ content to the console.
/* send a message on our channel */
err = rpmsg_send(rpdev->ept, "hello!", 6);
if (err) {
- pr_err("rpmsg_send failed: %d\n", err);
+ dev_err(&rpdev->dev, "rpmsg_send failed: %d\n", err);
return err;
}
--
2.50.1
^ permalink raw reply related
* Re: [PATCH RESEND v6] checkpatch: add uninitialized pointer with __free attribute check
From: ally heev @ 2025-11-26 14:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley
In-Reply-To: <4ef74e2b-74a9-4778-a3f2-d873cf6b7478@kernel.org>
On Wed, 2025-11-26 at 09:10 +0100, Krzysztof Kozlowski wrote:
> On 25/11/2025 17:11, ally heev wrote:
> > On Tue, 2025-11-25 at 16:09 +0100, Krzysztof Kozlowski wrote:
> > > On 25/11/2025 14:32, Ally Heev wrote:
> > > > uninitialized pointers with __free attribute can cause undefined
> > > > behavior as the memory randomly assigned to the pointer is freed
> > > > automatically when the pointer goes out of scope.
> > > > add check in checkpatch to detect such issues.
> > > >
> > > > Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > > Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> > > > Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> > > > Acked-by: Dan Williams <dan.j.williams@intel.com>
> > > > Signed-off-by: Ally Heev <allyheev@gmail.com>
> > >
> > >
> > > <form letter>
> > > This is a friendly reminder during the review process.
> > >
> > > It looks like you received a tag and forgot to add it.
> > >
> > > If you do not know the process, here is a short explanation:
> > > Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions
> > > of patchset, under or above your Signed-off-by tag, unless patch changed
> > > significantly (e.g. new properties added to the DT bindings). Tag is
> > > "received", when provided in a message replied to you on the mailing
> > > list. Tools like b4 can help here. However, there's no need to repost
> > > patches *only* to add the tags. The upstream maintainer will do that for
> > > tags received on the version they apply.
> > >
> > > Please read:
> > > https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
> > >
> > > If a tag was not added on purpose, please state why and what changed.
> > > </form letter>
> > >
> > >
> > > Best regards,
> > > Krzysztof
> >
> > Oopsie. I should have sent a new version instead of resending a failed
> > one. I have updated the `UNINITIALIZED_PTR_WITH_FREE` error description
> > in the checkpatch doc as outlined in v6 changelog, so, didn't add a
> > Reviewed-by tag
>
>
> Again, your changelog should explain the reason. Second, you implemented
> reviewer suggestion, received the tag so why do you think that Rb tag
> does not apply?
>
> Best regards,
> Krzysztof
Sorry again :(. I thought the new changes, although minor, would entail
new comments. I have experienced this in my old patches
Regards,
Ally
^ permalink raw reply
* [PATCH] docs: submitting-patches: Clarify that removal of Acks needs explanation too
From: Krzysztof Kozlowski @ 2025-11-26 8:19 UTC (permalink / raw)
To: Jonathan Corbet, workflows, linux-doc, linux-kernel; +Cc: Krzysztof Kozlowski
The paragraph mentions only removal of Tested-by and Reviewed-by tags as
action needing mentioning in patch changelog, so some developers treat
it too literally. Acks, as a weaker form of review/approval, should
rarely be removed, but if that happens it should be explained as well.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/process/submitting-patches.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 910e8fc9e3c8..9a509f1a6873 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -592,8 +592,9 @@ Both Tested-by and Reviewed-by tags, once received on mailing list from tester
or reviewer, should be added by author to the applicable patches when sending
next versions. However if the patch has changed substantially in following
version, these tags might not be applicable anymore and thus should be removed.
-Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
-in the patch changelog (after the '---' separator).
+Usually removal of someone's Acked-by, Tested-by or Reviewed-by tags should be
+mentioned in the patch changelog with an explanation (after the '---'
+separator).
A Suggested-by: tag indicates that the patch idea is suggested by the person
named and ensures credit to the person for the idea: if we diligently credit
--
2.48.1
^ permalink raw reply related
* Re: [PATCH RESEND v6] checkpatch: add uninitialized pointer with __free attribute check
From: Krzysztof Kozlowski @ 2025-11-26 8:10 UTC (permalink / raw)
To: ally heev, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley
In-Reply-To: <43f43063b81da41b693d5eb8178d5c55ebaaa168.camel@gmail.com>
On 25/11/2025 17:11, ally heev wrote:
> On Tue, 2025-11-25 at 16:09 +0100, Krzysztof Kozlowski wrote:
>> On 25/11/2025 14:32, Ally Heev wrote:
>>> uninitialized pointers with __free attribute can cause undefined
>>> behavior as the memory randomly assigned to the pointer is freed
>>> automatically when the pointer goes out of scope.
>>> add check in checkpatch to detect such issues.
>>>
>>> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
>>> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
>>> Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>> Signed-off-by: Ally Heev <allyheev@gmail.com>
>>
>>
>> <form letter>
>> This is a friendly reminder during the review process.
>>
>> It looks like you received a tag and forgot to add it.
>>
>> If you do not know the process, here is a short explanation:
>> Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions
>> of patchset, under or above your Signed-off-by tag, unless patch changed
>> significantly (e.g. new properties added to the DT bindings). Tag is
>> "received", when provided in a message replied to you on the mailing
>> list. Tools like b4 can help here. However, there's no need to repost
>> patches *only* to add the tags. The upstream maintainer will do that for
>> tags received on the version they apply.
>>
>> Please read:
>> https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
>>
>> If a tag was not added on purpose, please state why and what changed.
>> </form letter>
>>
>>
>> Best regards,
>> Krzysztof
>
> Oopsie. I should have sent a new version instead of resending a failed
> one. I have updated the `UNINITIALIZED_PTR_WITH_FREE` error description
> in the checkpatch doc as outlined in v6 changelog, so, didn't add a
> Reviewed-by tag
Again, your changelog should explain the reason. Second, you implemented
reviewer suggestion, received the tag so why do you think that Rb tag
does not apply?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5] README: restructure with role-based documentation and guidelines
From: SeongJae Park @ 2025-11-26 1:12 UTC (permalink / raw)
To: Sasha Levin
Cc: SeongJae Park, corbet, linux-doc, josh, kees, konstantin,
linux-kernel, rostedt, workflows, joe, rdunlap,
Mauro Carvalho Chehab
In-Reply-To: <20251121180009.2634393-1-sashal@kernel.org>
On Fri, 21 Nov 2025 13:00:09 -0500 Sasha Levin <sashal@kernel.org> wrote:
> Reorganize README to provide targeted documentation paths for different user
> roles including developers, researchers, security experts, and maintainers.
>
> Add quick start section and essential docs links.
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: SeongJae Park <sj@kernel.org>
> ---
>
> Changes since v4:
>
> - Remove explicit reference to GPLv2
> - Fix up the commit message to drop AI blurb
>
> README | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 149 insertions(+), 11 deletions(-)
>
> diff --git a/README b/README
> index fd903645e6de0..1fc993d7cf07e 100644
> --- a/README
> +++ b/README
> @@ -1,18 +1,156 @@
[...]
> +Documentation can be built with make htmldocs or viewed online at:
> +https://www.kernel.org/doc/html/latest/
> +
> +
> +Who Are You?
> +============
> +
> +Find your role below:
> +
> +* New Kernel Developer - Getting started with kernel development
> +* Academic Researcher - Studying kernel internals and architecture
> +* Security Expert - Hardening and vulnerability analysis
> +* Backport/Maintenance Engineer - Maintaining stable kernels
> +* System Administrator - Configuring and troubleshooting
> +* Maintainer - Leading subsystems and reviewing patches
> +* Hardware Vendor - Writing drivers for new hardware
> +* Distribution Maintainer - Packaging kernels for distros
> +
> +
> +For Specific Users
> +==================
> +
> +New Kernel Developer
> +--------------------
[...]
> +Distribution Maintainer
> +-----------------------
> +
> +Package and distribute the kernel:
> +
> +* Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst
> +* ABI Documentation: Documentation/ABI/README
> +* Kernel Configuration: Documentation/kbuild/kconfig.rst
> +* Module Signing: Documentation/admin-guide/module-signing.rst
> +* Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst
> +* Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst
> +
> +
> +
> +Communication and Support
> +=========================
Nit. Having only two blank lines above this section would make this document
look more consistent.
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH RESEND v6] checkpatch: add uninitialized pointer with __free attribute check
From: ally heev @ 2025-11-25 16:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley
In-Reply-To: <58393a1f-272b-41be-9ebd-ae03678cb738@kernel.org>
On Tue, 2025-11-25 at 16:09 +0100, Krzysztof Kozlowski wrote:
> On 25/11/2025 14:32, Ally Heev wrote:
> > uninitialized pointers with __free attribute can cause undefined
> > behavior as the memory randomly assigned to the pointer is freed
> > automatically when the pointer goes out of scope.
> > add check in checkpatch to detect such issues.
> >
> > Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> > Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> > Acked-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Ally Heev <allyheev@gmail.com>
>
>
> <form letter>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
> If you do not know the process, here is a short explanation:
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions
> of patchset, under or above your Signed-off-by tag, unless patch changed
> significantly (e.g. new properties added to the DT bindings). Tag is
> "received", when provided in a message replied to you on the mailing
> list. Tools like b4 can help here. However, there's no need to repost
> patches *only* to add the tags. The upstream maintainer will do that for
> tags received on the version they apply.
>
> Please read:
> https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
>
> If a tag was not added on purpose, please state why and what changed.
> </form letter>
>
>
> Best regards,
> Krzysztof
Oopsie. I should have sent a new version instead of resending a failed
one. I have updated the `UNINITIALIZED_PTR_WITH_FREE` error description
in the checkpatch doc as outlined in v6 changelog, so, didn't add a
Reviewed-by tag
For some reason gmail blocked me from sending v6 to everyone in the
patch except me. b4 thought it successfully sent the patch and
incremented the version number. So, I had to resend it
Thanks,
Ally
^ permalink raw reply
* Re: [PATCH RESEND v6] checkpatch: add uninitialized pointer with __free attribute check
From: Krzysztof Kozlowski @ 2025-11-25 15:09 UTC (permalink / raw)
To: Ally Heev, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley
In-Reply-To: <20251125-aheev-checkpatch-uninitialized-free-v6-1-70e8bb1e9175@gmail.com>
On 25/11/2025 14:32, Ally Heev wrote:
> uninitialized pointers with __free attribute can cause undefined
> behavior as the memory randomly assigned to the pointer is freed
> automatically when the pointer goes out of scope.
> add check in checkpatch to detect such issues.
>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ally Heev <allyheev@gmail.com>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new versions
of patchset, under or above your Signed-off-by tag, unless patch changed
significantly (e.g. new properties added to the DT bindings). Tag is
"received", when provided in a message replied to you on the mailing
list. Tools like b4 can help here. However, there's no need to repost
patches *only* to add the tags. The upstream maintainer will do that for
tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH RESEND v6] checkpatch: add uninitialized pointer with __free attribute check
From: Ally Heev @ 2025-11-25 13:32 UTC (permalink / raw)
To: Dwaipayan Ray, Lukas Bulwahn, Joe Perches, Jonathan Corbet,
Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley,
Krzysztof Kozlowski, Ally Heev
uninitialized pointers with __free attribute can cause undefined
behavior as the memory randomly assigned to the pointer is freed
automatically when the pointer goes out of scope.
add check in checkpatch to detect such issues.
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ally Heev <allyheev@gmail.com>
---
Testing:
ran checkpatch.pl before and after the change on
crypto/asymmetric_keys/x509_public_key.c, which has
both initialized with NULL and uninitialized pointers
---
Changes in v6:
- added declaration at the place of use suggestion
- Link to v5: https://lore.kernel.org/r/20251124-aheev-checkpatch-uninitialized-free-v5-1-0c523b1a3f5a@gmail.com
Changes in v5:
- fixed checkpatch doc
- Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
Changes in v4:
- fixed UNINITIALIZED_PTR_WITH_FREE description
- Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
Changes in v3:
- remove $FreeAttribute
- Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
Changes in v2:
- change cover letter and title to reflect new changes
- fix regex to handle multiple declarations in a single line case
- convert WARN to ERROR for uninitialized pointers
- add a new WARN for pointers initialized with NULL
- NOTE: tried handling multiple declarations on a single line by splitting
them and matching the parts with regex, but, it turned out to be
complex and overkill. Moreover, multi-line declarations pose a threat
- Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
---
Documentation/dev-tools/checkpatch.rst | 23 +++++++++++++++++++++++
scripts/checkpatch.pl | 6 ++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index d5c47e560324fb2399a5b1bc99c891ed1de10535..b6e02fb91e85710fecfc0a5e5c83a8e7f32d1d3c 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -1009,6 +1009,29 @@ Functions and Variables
return bar;
+ **UNINITIALIZED_PTR_WITH_FREE**
+ Pointers with __free attribute should be declared at the place of use
+ and initialized (see include/linux/cleanup.h). In this case
+ declarations at the top of the function rule can be relaxed. Not doing
+ so may lead to undefined behavior as the memory assigned (garbage,
+ in case not initialized) to the pointer is freed automatically when
+ the pointer goes out of scope.
+
+ Also see: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
+
+ Example::
+
+ type var __free(free_func);
+ ... // var not used, but, in future someone might add a return here
+ var = malloc(var_size);
+ ...
+
+ should be initialized as::
+
+ ...
+ type var __free(free_func) = malloc(var_size);
+ ...
+
Permissions
-----------
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92669904eecc7a8d2afd3f2625528e02b6d17cd6..e697d81d71c0b3628f7b59807e8bc40d582621bb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7721,6 +7721,12 @@ sub process {
ERROR("MISSING_SENTINEL", "missing sentinel in ID array\n" . "$here\n$stat\n");
}
}
+
+# check for uninitialized pointers with __free attribute
+ while ($line =~ /\*\s*($Ident)\s+__free\s*\(\s*$Ident\s*\)\s*[,;]/g) {
+ ERROR("UNINITIALIZED_PTR_WITH_FREE",
+ "pointer '$1' with __free attribute should be initialized\n" . $herecurr);
+ }
}
# If we have no input at all, then there is nothing to report on
---
base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08
change-id: 20251021-aheev-checkpatch-uninitialized-free-5c39f75e10a1
Best regards,
--
Ally Heev <allyheev@gmail.com>
^ permalink raw reply related
* Re: [PATCH v5] checkpatch: add uninitialized pointer with __free attribute check
From: Krzysztof Kozlowski @ 2025-11-24 14:52 UTC (permalink / raw)
To: Ally Heev, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley
In-Reply-To: <20251124-aheev-checkpatch-uninitialized-free-v5-1-0c523b1a3f5a@gmail.com>
On 24/11/2025 15:44, Ally Heev wrote:
> uninitialized pointers with __free attribute can cause undefined
> behavior as the memory randomly assigned to the pointer is freed
> automatically when the pointer goes out of scope.
> add check in checkpatch to detect such issues.
>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ally Heev <allyheev@gmail.com>
> ---
> Testing:
> ran checkpatch.pl before and after the change on
> crypto/asymmetric_keys/x509_public_key.c, which has
> both initialized with NULL and uninitialized pointers
> ---
> Changes in v5:
> - fixed checkpatch doc
> - Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
>
> Changes in v4:
> - fixed UNINITIALIZED_PTR_WITH_FREE description
> - Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
>
> Changes in v3:
> - remove $FreeAttribute
> - Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
>
> Changes in v2:
> - change cover letter and title to reflect new changes
> - fix regex to handle multiple declarations in a single line case
> - convert WARN to ERROR for uninitialized pointers
> - add a new WARN for pointers initialized with NULL
> - NOTE: tried handling multiple declarations on a single line by splitting
> them and matching the parts with regex, but, it turned out to be
> complex and overkill. Moreover, multi-line declarations pose a threat
> - Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
> ---
> Documentation/dev-tools/checkpatch.rst | 20 ++++++++++++++++++++
> scripts/checkpatch.pl | 6 ++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index d5c47e560324fb2399a5b1bc99c891ed1de10535..865aaaf6dc51b1c3f763b3cbb8713da3d00db960 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -1009,6 +1009,26 @@ Functions and Variables
>
> return bar;
>
> + **UNINITIALIZED_PTR_WITH_FREE**
> + Pointers with __free attribute should be defined and assigned in one
You did not implement my proposal fully. I wanted to express that their
declaration should be in the place of use, meaning first use.
> + statement. In this case declarations at the top of the function rule
This does not solve it, because one can declare, define and assign in
top part of the function not achieving what we want - place of use.
Not sure if it is worth debating on, so overall (although I did not
verify regex very thoroughly):
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5] checkpatch: add uninitialized pointer with __free attribute check
From: Ally Heev @ 2025-11-24 14:44 UTC (permalink / raw)
To: Dwaipayan Ray, Lukas Bulwahn, Joe Perches, Jonathan Corbet,
Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven, James Bottomley,
Krzysztof Kozlowski, Ally Heev
uninitialized pointers with __free attribute can cause undefined
behavior as the memory randomly assigned to the pointer is freed
automatically when the pointer goes out of scope.
add check in checkpatch to detect such issues.
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ally Heev <allyheev@gmail.com>
---
Testing:
ran checkpatch.pl before and after the change on
crypto/asymmetric_keys/x509_public_key.c, which has
both initialized with NULL and uninitialized pointers
---
Changes in v5:
- fixed checkpatch doc
- Link to v4: https://lore.kernel.org/r/20251107-aheev-checkpatch-uninitialized-free-v4-1-4822a6ac728f@gmail.com
Changes in v4:
- fixed UNINITIALIZED_PTR_WITH_FREE description
- Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
Changes in v3:
- remove $FreeAttribute
- Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
Changes in v2:
- change cover letter and title to reflect new changes
- fix regex to handle multiple declarations in a single line case
- convert WARN to ERROR for uninitialized pointers
- add a new WARN for pointers initialized with NULL
- NOTE: tried handling multiple declarations on a single line by splitting
them and matching the parts with regex, but, it turned out to be
complex and overkill. Moreover, multi-line declarations pose a threat
- Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
---
Documentation/dev-tools/checkpatch.rst | 20 ++++++++++++++++++++
scripts/checkpatch.pl | 6 ++++++
2 files changed, 26 insertions(+)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index d5c47e560324fb2399a5b1bc99c891ed1de10535..865aaaf6dc51b1c3f763b3cbb8713da3d00db960 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -1009,6 +1009,26 @@ Functions and Variables
return bar;
+ **UNINITIALIZED_PTR_WITH_FREE**
+ Pointers with __free attribute should be defined and assigned in one
+ statement. In this case declarations at the top of the function rule
+ can be relaxed. Not doing so may lead to undefined behavior as the
+ memory assigned (garbage, in case not initialized) to the pointer is
+ freed automatically when the pointer goes out of scope.
+
+ See: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
+
+ Example::
+
+ type var __free(free_func);
+ ... // function might have returned here
+ var = malloc(var_size);
+
+ should be initialized as::
+
+ type var __free(free_func) = malloc(var_size);
+ ... // return here would just free allocated memory
+
Permissions
-----------
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92669904eecc7a8d2afd3f2625528e02b6d17cd6..e697d81d71c0b3628f7b59807e8bc40d582621bb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7721,6 +7721,12 @@ sub process {
ERROR("MISSING_SENTINEL", "missing sentinel in ID array\n" . "$here\n$stat\n");
}
}
+
+# check for uninitialized pointers with __free attribute
+ while ($line =~ /\*\s*($Ident)\s+__free\s*\(\s*$Ident\s*\)\s*[,;]/g) {
+ ERROR("UNINITIALIZED_PTR_WITH_FREE",
+ "pointer '$1' with __free attribute should be initialized\n" . $herecurr);
+ }
}
# If we have no input at all, then there is nothing to report on
---
base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08
change-id: 20251021-aheev-checkpatch-uninitialized-free-5c39f75e10a1
Best regards,
--
Ally Heev <allyheev@gmail.com>
^ permalink raw reply related
* Re: [PATCH v5] README: restructure with role-based documentation and guidelines
From: Bagas Sanjaya @ 2025-11-23 0:06 UTC (permalink / raw)
To: Sasha Levin, corbet, linux-doc
Cc: josh, kees, konstantin, linux-kernel, rostedt, workflows, joe,
rdunlap, Mauro Carvalho Chehab
In-Reply-To: <20251121180009.2634393-1-sashal@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
On Fri, Nov 21, 2025 at 01:00:09PM -0500, Sasha Levin wrote:
> Reorganize README to provide targeted documentation paths for different user
> roles including developers, researchers, security experts, and maintainers.
>
> Add quick start section and essential docs links.
LGTM, thanks!
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v4] checkpatch: add uninitialized pointer with __free attribute check
From: ally heev @ 2025-11-22 17:28 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven
In-Reply-To: <f8b93a66-c755-497d-a425-c7b4baff5165@kernel.org>
On Sat, 2025-11-22 at 14:01 +0100, Krzysztof Kozlowski wrote:
[...]
> I saw the other discussion and Linus re-iterated old approach/syntax
> preference, thus I think this should also include it, since it is de
> facto a coding style:
>
> "Pointers with __free attribute should be declared in the place of use
> and initialized (see include/linux/cleanup.h)......"
>
> Best regards,
> Krzysztof
Yes. I am planning to do it in v5 along with coding style doc update
^ permalink raw reply
* Re: [PATCH RESEND v4] checkpatch: add uninitialized pointer with __free attribute check
From: Krzysztof Kozlowski @ 2025-11-22 13:01 UTC (permalink / raw)
To: Ally Heev, Dwaipayan Ray, Lukas Bulwahn, Joe Perches,
Jonathan Corbet, Andy Whitcroft
Cc: workflows, linux-doc, linux-kernel, Dan Carpenter, David Hunter,
Shuah Khan, Viresh Kumar, Nishanth Menon, Stephen Boyd, linux-pm,
dan.j.williams, Geert Uytterhoeven
In-Reply-To: <20251117-aheev-checkpatch-uninitialized-free-v4-1-fbee16ffeab9@gmail.com>
On 17/11/2025 04:10, Ally Heev wrote:
> uninitialized pointers with __free attribute can cause undefined
> behavior as the memory randomly assigned to the pointer is freed
> automatically when the pointer goes out of scope.
> add check in checkpatch to detect such issues.
>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ally Heev <allyheev@gmail.com>
> ---
> Testing:
> ran checkpatch.pl before and after the change on
> crypto/asymmetric_keys/x509_public_key.c, which has
> both initialized with NULL and uninitialized pointers
> ---
> Changes in v4:
> - fixed UNINITIALIZED_PTR_WITH_FREE description
> - Link to v3: https://lore.kernel.org/r/20251025-aheev-checkpatch-uninitialized-free-v3-1-a67f72b1c2bd@gmail.com
>
> Changes in v3:
> - remove $FreeAttribute
> - Link to v2: https://lore.kernel.org/r/20251024-aheev-checkpatch-uninitialized-free-v2-0-16c0900e8130@gmail.com
>
> Changes in v2:
> - change cover letter and title to reflect new changes
> - fix regex to handle multiple declarations in a single line case
> - convert WARN to ERROR for uninitialized pointers
> - add a new WARN for pointers initialized with NULL
> - NOTE: tried handling multiple declarations on a single line by splitting
> them and matching the parts with regex, but, it turned out to be
> complex and overkill. Moreover, multi-line declarations pose a threat
> - Link to v1: https://lore.kernel.org/r/20251021-aheev-checkpatch-uninitialized-free-v1-1-18fb01bc6a7a@gmail.com
> ---
> Documentation/dev-tools/checkpatch.rst | 5 +++++
> scripts/checkpatch.pl | 6 ++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index d5c47e560324fb2399a5b1bc99c891ed1de10535..c61a3892a60c13f7c5ba89e969e39a93a3dcd5bc 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -1009,6 +1009,11 @@ Functions and Variables
>
> return bar;
>
> + **UNINITIALIZED_PTR_WITH_FREE**
> + Pointers with __free attribute should be initialized. Not doing so
I saw the other discussion and Linus re-iterated old approach/syntax
preference, thus I think this should also include it, since it is de
facto a coding style:
"Pointers with __free attribute should be declared in the place of use
and initialized (see include/linux/cleanup.h)......"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5] README: restructure with role-based documentation and guidelines
From: Joe Perches @ 2025-11-21 18:29 UTC (permalink / raw)
To: Sasha Levin, corbet, linux-doc
Cc: josh, kees, konstantin, linux-kernel, rostedt, workflows, rdunlap,
Mauro Carvalho Chehab
In-Reply-To: <20251121180009.2634393-1-sashal@kernel.org>
On Fri, 2025-11-21 at 13:00 -0500, Sasha Levin wrote:
> Reorganize README to provide targeted documentation paths for different user
> roles including developers, researchers, security experts, and maintainers.
Thank you Sasha. Looks great.
^ permalink raw reply
* [PATCH v5] README: restructure with role-based documentation and guidelines
From: Sasha Levin @ 2025-11-21 18:00 UTC (permalink / raw)
To: corbet, linux-doc
Cc: josh, kees, konstantin, linux-kernel, rostedt, workflows, joe,
rdunlap, Sasha Levin, Mauro Carvalho Chehab
Reorganize README to provide targeted documentation paths for different user
roles including developers, researchers, security experts, and maintainers.
Add quick start section and essential docs links.
Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
---
Changes since v4:
- Remove explicit reference to GPLv2
- Fix up the commit message to drop AI blurb
README | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 149 insertions(+), 11 deletions(-)
diff --git a/README b/README
index fd903645e6de0..1fc993d7cf07e 100644
--- a/README
+++ b/README
@@ -1,18 +1,156 @@
Linux kernel
============
-There are several guides for kernel developers and users. These guides can
-be rendered in a number of formats, like HTML and PDF. Please read
-Documentation/admin-guide/README.rst first.
+The Linux kernel is the core of any Linux operating system. It manages hardware,
+system resources, and provides the fundamental services for all other software.
-In order to build the documentation, use ``make htmldocs`` or
-``make pdfdocs``. The formatted documentation can also be read online at:
+Quick Start
+-----------
- https://www.kernel.org/doc/html/latest/
+* Report a bug: See Documentation/admin-guide/reporting-issues.rst
+* Get the latest kernel: https://kernel.org
+* Build the kernel: See Documentation/admin-guide/quickly-build-trimmed-linux.rst
+* Join the community: https://lore.kernel.org/
-There are various text files in the Documentation/ subdirectory,
-several of them using the reStructuredText markup notation.
+Essential Documentation
+-----------------------
-Please read the Documentation/process/changes.rst file, as it contains the
-requirements for building and running the kernel, and information about
-the problems which may result by upgrading your kernel.
+All users should be familiar with:
+
+* Building requirements: Documentation/process/changes.rst
+* Code of Conduct: Documentation/process/code-of-conduct.rst
+* License: See COPYING
+
+Documentation can be built with make htmldocs or viewed online at:
+https://www.kernel.org/doc/html/latest/
+
+
+Who Are You?
+============
+
+Find your role below:
+
+* New Kernel Developer - Getting started with kernel development
+* Academic Researcher - Studying kernel internals and architecture
+* Security Expert - Hardening and vulnerability analysis
+* Backport/Maintenance Engineer - Maintaining stable kernels
+* System Administrator - Configuring and troubleshooting
+* Maintainer - Leading subsystems and reviewing patches
+* Hardware Vendor - Writing drivers for new hardware
+* Distribution Maintainer - Packaging kernels for distros
+
+
+For Specific Users
+==================
+
+New Kernel Developer
+--------------------
+
+Welcome! Start your kernel development journey here:
+
+* Getting Started: Documentation/process/development-process.rst
+* Your First Patch: Documentation/process/submitting-patches.rst
+* Coding Style: Documentation/process/coding-style.rst
+* Build System: Documentation/kbuild/index.rst
+* Development Tools: Documentation/dev-tools/index.rst
+* Kernel Hacking Guide: Documentation/kernel-hacking/hacking.rst
+* Core APIs: Documentation/core-api/index.rst
+
+Academic Researcher
+-------------------
+
+Explore the kernel's architecture and internals:
+
+* Researcher Guidelines: Documentation/process/researcher-guidelines.rst
+* Memory Management: Documentation/mm/index.rst
+* Scheduler: Documentation/scheduler/index.rst
+* Networking Stack: Documentation/networking/index.rst
+* Filesystems: Documentation/filesystems/index.rst
+* RCU (Read-Copy Update): Documentation/RCU/index.rst
+* Locking Primitives: Documentation/locking/index.rst
+* Power Management: Documentation/power/index.rst
+
+Security Expert
+---------------
+
+Security documentation and hardening guides:
+
+* Security Documentation: Documentation/security/index.rst
+* LSM Development: Documentation/security/lsm-development.rst
+* Self Protection: Documentation/security/self-protection.rst
+* Reporting Vulnerabilities: Documentation/process/security-bugs.rst
+* CVE Procedures: Documentation/process/cve.rst
+* Embargoed Hardware Issues: Documentation/process/embargoed-hardware-issues.rst
+* Security Features: Documentation/userspace-api/seccomp_filter.rst
+
+Backport/Maintenance Engineer
+-----------------------------
+
+Maintain and stabilize kernel versions:
+
+* Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst
+* Backporting Guide: Documentation/process/backporting.rst
+* Applying Patches: Documentation/process/applying-patches.rst
+* Subsystem Profile: Documentation/maintainer/maintainer-entry-profile.rst
+* Git for Maintainers: Documentation/maintainer/configure-git.rst
+
+System Administrator
+--------------------
+
+Configure, tune, and troubleshoot Linux systems:
+
+* Admin Guide: Documentation/admin-guide/index.rst
+* Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst
+* Sysctl Tuning: Documentation/admin-guide/sysctl/index.rst
+* Tracing/Debugging: Documentation/trace/index.rst
+* Performance Security: Documentation/admin-guide/perf-security.rst
+* Hardware Monitoring: Documentation/hwmon/index.rst
+
+Maintainer
+----------
+
+Lead kernel subsystems and manage contributions:
+
+* Maintainer Handbook: Documentation/maintainer/index.rst
+* Pull Requests: Documentation/maintainer/pull-requests.rst
+* Managing Patches: Documentation/maintainer/modifying-patches.rst
+* Rebasing and Merging: Documentation/maintainer/rebasing-and-merging.rst
+* Development Process: Documentation/process/maintainer-handbooks.rst
+* Maintainer Entry Profile: Documentation/maintainer/maintainer-entry-profile.rst
+* Git Configuration: Documentation/maintainer/configure-git.rst
+
+Hardware Vendor
+---------------
+
+Write drivers and support new hardware:
+
+* Driver API Guide: Documentation/driver-api/index.rst
+* Driver Model: Documentation/driver-api/driver-model/driver.rst
+* Device Drivers: Documentation/driver-api/infrastructure.rst
+* Bus Types: Documentation/driver-api/driver-model/bus.rst
+* Device Tree Bindings: Documentation/devicetree/bindings/
+* Power Management: Documentation/driver-api/pm/index.rst
+* DMA API: Documentation/core-api/dma-api.rst
+
+Distribution Maintainer
+-----------------------
+
+Package and distribute the kernel:
+
+* Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst
+* ABI Documentation: Documentation/ABI/README
+* Kernel Configuration: Documentation/kbuild/kconfig.rst
+* Module Signing: Documentation/admin-guide/module-signing.rst
+* Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst
+* Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst
+
+
+
+Communication and Support
+=========================
+
+* Mailing Lists: https://lore.kernel.org/
+* IRC: #kernelnewbies on irc.oftc.net
+* Bugzilla: https://bugzilla.kernel.org/
+* MAINTAINERS file: Lists subsystem maintainers and mailing lists
+* Email Clients: Documentation/process/email-clients.rst
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4] README: restructure with role-based documentation and guidelines
From: Kees Cook @ 2025-11-19 22:34 UTC (permalink / raw)
To: Sasha Levin
Cc: corbet, linux-doc, josh, konstantin, linux-kernel, rostedt,
workflows, joe, rdunlap
In-Reply-To: <20251119023832.1095490-1-sashal@kernel.org>
On Tue, Nov 18, 2025 at 09:38:32PM -0500, Sasha Levin wrote:
> Reorganize README to provide targeted documentation paths for different user
> roles including developers, researchers, security experts, maintainers, and AI
> coding assistants. Add quick start section and essential docs links.
>
> Include proper attribution requirements for AI-assisted contributions using
> Assisted-by tags with agent details and tools used.
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> Changes since v3:
>
> - No AI hype :)
> - Link to a guide for building the kernel
Thanks! With the other comments in the v4 thread fixed:
Reviewed-by: Kees Cook <kees@kernel.org>
-Kees
--
Kees Cook
^ 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