* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Vlastimil Babka @ 2026-03-30 9:40 UTC (permalink / raw)
To: Joe Perches, Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <f4dcaecb682c4eaa271abfee27c7cc8f6fbf7d1d.camel@perches.com>
On 3/27/26 00:19, Joe Perches wrote:
> On Thu, 2026-03-26 at 16:04 -0700, Dmitry Torokhov wrote:
>> In all seriousness, if you will not make use of this mode it's fine. But
>> it allows keeping the source cleaner as one makes edits, so why not
>> enable this?
>
> Unnecessary complication.
Are you maintaining a tool that you want to be useful to others, or to only
do stricly what you personally think is necessary?
I don't understand your objections to this rather straightforward patch, it
doesn't look like a maintenance burden to me?
^ permalink raw reply
* [PATCH] Doc: process: Added two important books for Linux Kernel programming and development
From: Bhaskar Chowdhury @ 2026-03-28 7:40 UTC (permalink / raw)
To: corbet, skhan, workflows, linux-doc, linux-kernel; +Cc: Bhaskar Chowdhury
These books are very well written and enhance the understanding of the process.
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
Documentation/process/howto.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6f50..c5164a27fc1a 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -34,7 +34,8 @@ experience, the following books are good for, if anything, reference:
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" by Steve Oualline [O'Reilly]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
-
+ - "Linux System Programming" by Robert Love [O'Reilly]
+ - "Linux Kernel Development" By Robert Love [Pearson]
The kernel is written using GNU C and the GNU toolchain. While it
adheres to the ISO C11 standard, it uses a number of extensions that are
not featured in the standard. The kernel is a freestanding C
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] Documentation: Provide hints on how to debug Python GDB scripts
From: Radu Rendec @ 2026-03-27 17:50 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel, akpm
Cc: tglx, Jonathan Corbet, Shuah Khan, Illia Ostapyshyn,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION
In-Reply-To: <20260326233226.2248817-1-florian.fainelli@broadcom.com>
On Thu, 2026-03-26 at 16:32 -0700, Florian Fainelli wrote:
> By default GDB does not print a full stack of its integrated Python
> interpreter, thus making the debugging of GDB scripts more painful than
> it has to be.
>
> Suggested-by: Radu Rendec <radu@rendec.net>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/process/debugging/gdb-kernel-debugging.rst | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst
> index 9475c759c722..53e225760a4d 100644
> --- a/Documentation/process/debugging/gdb-kernel-debugging.rst
> +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst
> @@ -173,3 +173,12 @@ this is just a snapshot of the initial version::
>
> Detailed help can be obtained via "help <command-name>" for commands and "help
> function <function-name>" for convenience functions.
> +
> +Debugging GDB scripts
> +---------------------
> +
> +GDB does not enable a full Python backtrace which can make debugging GDB
> +scripts more difficult than necessary. The following will allow for printing a
> +full backtrace of the python environment::
> +
> + (gdb) set python print-stack full
Reviewed-by: Radu Rendec <radu@rendec.net>
^ permalink raw reply
* [PATCH] Documentation: Provide hints on how to debug Python GDB scripts
From: Florian Fainelli @ 2026-03-26 23:32 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: tglx, radu, Florian Fainelli, Jonathan Corbet, Shuah Khan,
Illia Ostapyshyn, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION
By default GDB does not print a full stack of its integrated Python
interpreter, thus making the debugging of GDB scripts more painful than
it has to be.
Suggested-by: Radu Rendec <radu@rendec.net>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
Documentation/process/debugging/gdb-kernel-debugging.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst
index 9475c759c722..53e225760a4d 100644
--- a/Documentation/process/debugging/gdb-kernel-debugging.rst
+++ b/Documentation/process/debugging/gdb-kernel-debugging.rst
@@ -173,3 +173,12 @@ this is just a snapshot of the initial version::
Detailed help can be obtained via "help <command-name>" for commands and "help
function <function-name>" for convenience functions.
+
+Debugging GDB scripts
+---------------------
+
+GDB does not enable a full Python backtrace which can make debugging GDB
+scripts more difficult than necessary. The following will allow for printing a
+full backtrace of the python environment::
+
+ (gdb) set python print-stack full
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 23:27 UTC (permalink / raw)
To: Dmitry Torokhov, Andrew Morton
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acW9KGbNm8bLg-cr@google.com>
On Thu, 2026-03-26 at 16:19 -0700, Dmitry Torokhov wrote:
> On Thu, Mar 26, 2026 at 03:56:27PM -0700, Joe Perches wrote:
> I gave you feedback. You elided it.
> > > Could you please point me to it? All I saw is "just save it"
> > Seems constructive to me.
> As constructive as "You're holding it wrong". I want to be able to run
> checkpatch as I am typing, not at some later time. My editor shows
> diagnostics as a virtual text, so it is quite confusing that the error
> is still shown even after I fixed the issue.
>
> It looks like I forgot to add akpm to CC, let me add him...
No worries. nak.
It's not something I want to support.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 23:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acW6Iar6XOzO9IfN@google.com>
On Thu, 2026-03-26 at 16:04 -0700, Dmitry Torokhov wrote:
> In all seriousness, if you will not make use of this mode it's fine. But
> it allows keeping the source cleaner as one makes edits, so why not
> enable this?
Unnecessary complication.
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Dmitry Torokhov @ 2026-03-26 23:19 UTC (permalink / raw)
To: Joe Perches, Andrew Morton
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <3217a61e50f7b9fd387b908c0907bd0bf889bebb.camel@perches.com>
On Thu, Mar 26, 2026 at 04:10:05PM -0700, Joe Perches wrote:
> On Thu, 2026-03-26 at 16:04 -0700, Dmitry Torokhov wrote:
> > On Thu, Mar 26, 2026 at 03:56:27PM -0700, Joe Perches wrote:
> > > I gave you feedback. You elided it.
> > Could you please point me to it? All I saw is "just save it"
>
> Seems constructive to me.
As constructive as "You're holding it wrong". I want to be able to run
checkpatch as I am typing, not at some later time. My editor shows
diagnostics as a virtual text, so it is quite confusing that the error
is still shown even after I fixed the issue.
It looks like I forgot to add akpm to CC, let me add him...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 23:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acW6Iar6XOzO9IfN@google.com>
On Thu, 2026-03-26 at 16:04 -0700, Dmitry Torokhov wrote:
> On Thu, Mar 26, 2026 at 03:56:27PM -0700, Joe Perches wrote:
> > I gave you feedback. You elided it.
> Could you please point me to it? All I saw is "just save it"
Seems constructive to me.
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Dmitry Torokhov @ 2026-03-26 23:04 UTC (permalink / raw)
To: Joe Perches
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <34318752a257b0f6b530eacf53d565de1ac84485.camel@perches.com>
On Thu, Mar 26, 2026 at 03:56:27PM -0700, Joe Perches wrote:
> On Thu, 2026-03-26 at 14:42 -0700, Dmitry Torokhov wrote:
> > > > Because when I am editing a file I am not saving it all that often. I
> > > > want to have buffer diagnostic updated when I leave insert mode in vim.
> > >
> > > I believe you are able to keep your own version of checkpatch.
> >
> > As well as my version of the kernel, gcc, clang, editor, git and so on.
> >
> > Do you have any constructive feedback?
>
> I gave you feedback. You elided it.
Could you please point me to it? All I saw is "just save it" and "keep
your own copy". Neither of this suggestions are particularly useful.
>
> > Right now checkpatch is broken
> > when using "-f" with stdin and I offer a fix. If you have a better way
> > in mind by all means share it.
>
> Note the name. Feed it a patch. It works fine. It's not broken.
This option is a bug then and should be removed:
"-f, --file treat FILE as regular source file"
right?
In all seriousness, if you will not make use of this mode it's fine. But
it allows keeping the source cleaner as one makes edits, so why not
enable this?
--
Dmitry
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 22:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acWnbG3nGjfYeYXh@google.com>
On Thu, 2026-03-26 at 14:42 -0700, Dmitry Torokhov wrote:
> > > Because when I am editing a file I am not saving it all that often. I
> > > want to have buffer diagnostic updated when I leave insert mode in vim.
> >
> > I believe you are able to keep your own version of checkpatch.
>
> As well as my version of the kernel, gcc, clang, editor, git and so on.
>
> Do you have any constructive feedback?
I gave you feedback. You elided it.
> Right now checkpatch is broken
> when using "-f" with stdin and I offer a fix. If you have a better way
> in mind by all means share it.
Note the name. Feed it a patch. It works fine. It's not broken.
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Dmitry Torokhov @ 2026-03-26 21:42 UTC (permalink / raw)
To: Joe Perches
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <117b6a4c164a9f0ce348044152d00ac22b31b81b.camel@perches.com>
On Thu, Mar 26, 2026 at 02:36:35PM -0700, Joe Perches wrote:
> On Thu, 2026-03-26 at 07:53 -0700, Dmitry Torokhov wrote:
> > On Thu, Mar 26, 2026 at 01:46:49AM -0700, Joe Perches wrote:
> > On Wed, 2026-03-25 at 23:20 -0700, Dmitry Torokhov wrote:
> > checkpatch does not handle full files well when they are passed on
> > > > stdin, because it does not know how to treat the text, and whether it is
> > > > a C file, or a DTS file, or something else, and so it assumes that when
> > > > it works with stdin it should be a unified diff. For full files it
> > > > expects to have a file name as an argument and read the contents from
> > > > disk. Unfortunately this does not well when trying to use checkpatch as
> > > > an online linter and feed it contents of an editor buffer that have not
> > > > made it to the disk yet.
> > >
> > > Why is this useful?
> > > Why not save the buffer and then feed the file?
> >
> > Because when I am editing a file I am not saving it all that often. I
> > want to have buffer diagnostic updated when I leave insert mode in vim.
>
> I believe you are able to keep your own version of checkpatch.
As well as my version of the kernel, gcc, clang, editor, git and so on.
Do you have any constructive feedback? Right now checkpatch is broken
when using "-f" with stdin and I offer a fix. If you have a better way
in mind by all means share it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 21:36 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acVIBseRrqJI8Uwb@google.com>
On Thu, 2026-03-26 at 07:53 -0700, Dmitry Torokhov wrote:
> On Thu, Mar 26, 2026 at 01:46:49AM -0700, Joe Perches wrote:
> On Wed, 2026-03-25 at 23:20 -0700, Dmitry Torokhov wrote:
> checkpatch does not handle full files well when they are passed on
> > > stdin, because it does not know how to treat the text, and whether it is
> > > a C file, or a DTS file, or something else, and so it assumes that when
> > > it works with stdin it should be a unified diff. For full files it
> > > expects to have a file name as an argument and read the contents from
> > > disk. Unfortunately this does not well when trying to use checkpatch as
> > > an online linter and feed it contents of an editor buffer that have not
> > > made it to the disk yet.
> >
> > Why is this useful?
> > Why not save the buffer and then feed the file?
>
> Because when I am editing a file I am not saving it all that often. I
> want to have buffer diagnostic updated when I leave insert mode in vim.
I believe you are able to keep your own version of checkpatch.
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Dmitry Torokhov @ 2026-03-26 14:53 UTC (permalink / raw)
To: Joe Perches
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <bb47800754aa3279e88c9d88c380bcfe6263fb2d.camel@perches.com>
On Thu, Mar 26, 2026 at 01:46:49AM -0700, Joe Perches wrote:
> On Wed, 2026-03-25 at 23:20 -0700, Dmitry Torokhov wrote:
> > checkpatch does not handle full files well when they are passed on
> > stdin, because it does not know how to treat the text, and whether it is
> > a C file, or a DTS file, or something else, and so it assumes that when
> > it works with stdin it should be a unified diff. For full files it
> > expects to have a file name as an argument and read the contents from
> > disk. Unfortunately this does not well when trying to use checkpatch as
> > an online linter and feed it contents of an editor buffer that have not
> > made it to the disk yet.
>
> Why is this useful?
> Why not save the buffer and then feed the file?
Because when I am editing a file I am not saving it all that often. I
want to have buffer diagnostic updated when I leave insert mode in vim.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 8:46 UTC (permalink / raw)
To: Dmitry Torokhov, Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acTPXMJfkHLeItrK@google.com>
On Wed, 2026-03-25 at 23:20 -0700, Dmitry Torokhov wrote:
> checkpatch does not handle full files well when they are passed on
> stdin, because it does not know how to treat the text, and whether it is
> a C file, or a DTS file, or something else, and so it assumes that when
> it works with stdin it should be a unified diff. For full files it
> expects to have a file name as an argument and read the contents from
> disk. Unfortunately this does not well when trying to use checkpatch as
> an online linter and feed it contents of an editor buffer that have not
> made it to the disk yet.
Why is this useful?
Why not save the buffer and then feed the file?
^ permalink raw reply
* [PATCH] checkpatch: allow correctly handle full files on stdin
From: Dmitry Torokhov @ 2026-03-26 6:20 UTC (permalink / raw)
To: Dwaipayan Ray, Lukas Bulwahn, Joe Perches, Andy Whitcroft
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
checkpatch does not handle full files well when they are passed on
stdin, because it does not know how to treat the text, and whether it is
a C file, or a DTS file, or something else, and so it assumes that when
it works with stdin it should be a unified diff. For full files it
expects to have a file name as an argument and read the contents from
disk. Unfortunately this does not well when trying to use checkpatch as
an online linter and feed it contents of an editor buffer that have not
made it to the disk yet.
To solve the above introduce a new optional argument --stdin-filename=FILE
that allows tell checkpatch the kind of file it is dealing with and
apply appropriate set of checks and rules to it.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Documentation/dev-tools/checkpatch.rst | 4 ++++
scripts/checkpatch.pl | 11 +++++++++++
2 files changed, 15 insertions(+)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index dccede68698c..b521e3ca6ebf 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -68,6 +68,10 @@ Available options:
Show the diffed file position instead of the input file position.
+ - --stdin-filename
+
+ When using stdin, identify the file as FILE.
+
- -g, --git
Treat FILE as a single commit or a git revision range.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e56374662ff7..e26951ceb36b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -57,6 +57,7 @@ my %ignore_type = ();
my @ignore = ();
my $help = 0;
my $configuration_file = ".checkpatch.conf";
+my $stdin_filename;
my $max_line_length = 100;
my $ignore_perl_version = 0;
my $minimum_perl_version = 5.10.0;
@@ -94,6 +95,7 @@ Options:
--emacs emacs compile window format
--terse one line per report
--showfile emit diffed file position, not input file position
+ --stdin-filename=FILE when using stdin, identify the file as FILE
-g, --git treat FILE as a single commit or git revision range
single git commit with:
<rev>
@@ -323,6 +325,7 @@ GetOptions(
'showfile!' => \$showfile,
'f|file!' => \$file,
'g|git!' => \$git,
+ 'stdin-filename=s' => \$stdin_filename,
'subjective!' => \$check,
'strict!' => \$check,
'ignore=s' => \@ignore,
@@ -2652,6 +2655,10 @@ sub is_userspace {
sub process {
my $filename = shift;
+ if ($filename eq '-' && defined($stdin_filename)) {
+ $filename = $stdin_filename;
+ }
+
my $linenr=0;
my $prevline="";
my $prevrawline="";
@@ -2891,6 +2898,10 @@ sub process {
$realfile =~ s@^([^/]*)/@@ if (!$file);
$in_commit_log = 0;
+ if ($realfile eq "-" && defined($stdin_filename)) {
+ $realfile = $stdin_filename;
+ }
+
$p1_prefix = $1;
if (!$file && $tree && $p1_prefix ne '' &&
-e "$root/$p1_prefix") {
--
2.53.0.1018.g2bb0e51243-goog
--
Dmitry
^ permalink raw reply related
* [PATCH v5 2/2] workflows, scripts: sort ver_linux and changes.rst
From: Manuel Ebner @ 2026-03-25 19:48 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194326.77923-2-manuelebner@mailbox.org>
sort output of scripts/ver_linux alphabetically
sort list in changes.rst alphabetically
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/changes.rst | 52 ++++++++++++-------------
scripts/ver_linux | 64 +++++++++++++++----------------
2 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index d94503341254..6ba9ca928e49 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -30,41 +30,41 @@ you probably do not need to concern yourself with pcmciautils.
====================== =============== ========================================
Program Minimal version Command to check the version
====================== =============== ========================================
-GNU C 8.1 gcc --version
-Clang/LLVM (optional) 15.0.0 clang --version
-Rust (optional) 1.78.0 rustc --version
-bindgen (optional) 0.65.1 bindgen --version
-GNU make 4.0 make --version
bash 4.2 bash --version
+bc 1.06.95 bc --version
+bindgen (optional) 0.65.1 bindgen --version
binutils 2.30 ld -v
-flex 2.5.35 flex --version
bison 2.0 bison --version
-pahole 1.22 pahole --version
-util-linux 2.10o mount --version
-kmod 13 kmod -V
+btrfs-progs 0.18 btrfs --version
+Clang/LLVM (optional) 15.0.0 clang --version
e2fsprogs 1.41.4 e2fsck -V
+flex 2.5.35 flex --version
+gdb 7.2 gdb --version
+GNU awk (optional) 5.1.0 gawk --version
+GNU C 8.1 gcc --version
+GNU make 4.0 make --version
+GNU tar 1.28 tar --version
+GRUB 0.93 grub --version || grub-install --version
+gtags (optional) 6.6.5 gtags --version
+iptables 1.4.2 iptables -V
jfsutils 1.1.3 fsck.jfs -V
-xfsprogs 2.6.0 xfs_db -V
-squashfs-tools 4.0 mksquashfs -version
-btrfs-progs 0.18 btrfs --version
+kmod 13 kmod -V
+mcelog 0.6 mcelog --version
+mkimage (optional) 2017.01 mkimage --version
+nfs-utils 1.0.5 showmount --version
+openssl & libcrypto 1.0.0 openssl version
+pahole 1.22 pahole --version
pcmciautils 004 pccardctl -V
-quota-tools 3.09 quota -V
PPP 2.4.0 pppd --version
-nfs-utils 1.0.5 showmount --version
procps 3.2.0 ps --version
-udev 081 udevadm --version
-GRUB 0.93 grub --version || grub-install --version
-mcelog 0.6 mcelog --version
-iptables 1.4.2 iptables -V
-openssl & libcrypto 1.0.0 openssl version
-bc 1.06.95 bc --version
-Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
-GNU tar 1.28 tar --version
-gtags (optional) 6.6.5 gtags --version
-mkimage (optional) 2017.01 mkimage --version
Python 3.9.x python3 --version
-GNU awk (optional) 5.1.0 gawk --version
-gdb 7.2 gdb --version
+quota-tools 3.09 quota -V
+Rust (optional) 1.78.0 rustc --version
+Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
+squashfs-tools 4.0 mksquashfs -version
+udev 081 udevadm --version
+util-linux 2.10o mount --version
+xfsprogs 2.6.0 xfs_db -V
====================== =============== ========================================
.. [#f1] Sphinx is needed only to build the Kernel documentation
diff --git a/scripts/ver_linux b/scripts/ver_linux
index fab0c68a6c52..00bdaf30d590 100755
--- a/scripts/ver_linux
+++ b/scripts/ver_linux
@@ -17,58 +17,58 @@ BEGIN {
libc = "libc[.]so[.][0-9]+$"
libcpp = "(libg|stdc)[+]+[.]so([.][0-9]+)+$"
- printversion("GNU C", version("gcc -dumpversion"))
- printversion("GNU make", version("make --version"))
- printversion("binutils", version("ld -v"))
- printversion("util-linux", version("mount --version"))
- printversion("Mount", version("mount --version"))
- printversion("Module-init-tools", version("depmod -V"))
- printversion("e2fsprogs", version("e2fsck -V"))
- printversion("jfsutils", version("fsck.jfs -V"))
- printversion("xfsprogs", version("xfs_db -V"))
- printversion("pcmciautils", version("pccardctl -V"))
- printversion("Pcmcia-cs", version("cardmgr -V"))
- printversion("quota-tools", version("quota -V"))
- printversion("PPP", version("pppd --version"))
- printversion("Isdn4k-utils", version("isdnctrl"))
- printversion("nfs-utils", version("showmount --version"))
- printversion("bison", version("bison --version"))
- printversion("flex", version("flex --version"))
-
- while ("ldconfig -p 2>/dev/null" | getline > 0)
- if ($NF ~ libc || $NF ~ libcpp)
- if (!seen[ver = version("readlink " $NF)]++)
- printversion("Linux C" ($NF ~ libcpp? "++" : "") " Library", ver)
-
- printversion("Dynamic linker (ldd)", version("ldd --version"))
- printversion("procps", version("ps --version"))
- printversion("Net-tools", version("ifconfig --version"))
- printversion("Kbd", version("loadkeys -V"))
- printversion("Console-tools", version("loadkeys -V"))
- printversion("Sh-utils", version("expr --v"))
- printversion("udev", version("udevadm --version"))
- printversion("Wireless-tools", version("iwconfig --version"))
printversion("bash", version("bash --version"))
printversion("bc", version("bc --version"))
printversion("bindgen", version("bindgen --version"))
+ printversion("binutils", version("ld -v"))
+ printversion("bison", version("bison --version"))
printversion("btrfs-progs", version("btrfs --version"))
printversion("Clang", version("clang --version"))
+ printversion("Console-tools", version("loadkeys -V"))
+ printversion("Dynamic linker (ldd)", version("ldd --version"))
+ printversion("e2fsprogs", version("e2fsck -V"))
+ printversion("flex", version("flex --version"))
printversion("gdb", version("gdb -version"))
printversion("GNU awk", version("gawk --version"))
+ printversion("GNU C", version("gcc -dumpversion"))
+ printversion("GNU make", version("make --version"))
printversion("GNU tar", version("tar --version"))
- printversion("GRUB", version("grub-install --version"))
printversion("GRUB2", version("grub2-install --version"))
+ printversion("GRUB", version("grub-install --version"))
printversion("gtags", version("gtags --version"))
printversion("iptables", version("iptables -V"))
+ printversion("Isdn4k-utils", version("isdnctrl"))
+ printversion("jfsutils", version("fsck.jfs -V"))
+ printversion("Kbd", version("loadkeys -V"))
printversion("kmod", version("kmod -V"))
+
+ while ("ldconfig -p 2>/dev/null" | getline > 0)
+ if ($NF ~ libc || $NF ~ libcpp)
+ if (!seen[ver = version("readlink " $NF)]++)
+ printversion("Linux C" ($NF ~ libcpp? "++" : "") " Library", ver)
+
printversion("mcelog", version("mcelog --version"))
printversion("mkimage", version("mkimage --version"))
+ printversion("Module-init-tools", version("depmod -V"))
+ printversion("Mount", version("mount --version"))
+ printversion("Net-tools", version("ifconfig --version"))
+ printversion("nfs-utils", version("showmount --version"))
printversion("openssl", version("openssl version"))
printversion("pahole", version("pahole --version"))
+ printversion("Pcmcia-cs", version("cardmgr -V"))
+ printversion("pcmciautils", version("pccardctl -V"))
+ printversion("PPP", version("pppd --version"))
+ printversion("procps", version("ps --version"))
printversion("Python", version("python3 -V"))
+ printversion("quota-tools", version("quota -V"))
printversion("Rust", version("rustc --version"))
+ printversion("Sh-utils", version("expr --v"))
printversion("Sphinx", version("sphinx-build --version"))
printversion("squashfs-tools", version("mksquashfs -version"))
+ printversion("udev", version("udevadm --version"))
+ printversion("util-linux", version("mount --version"))
+ printversion("Wireless-tools", version("iwconfig --version"))
+ printversion("xfsprogs", version("xfs_db -V"))
while ("sort /proc/modules" | getline > 0) {
mods = mods sep $1
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/2] workflows, scripts: harmonize and cleanup
From: Manuel Ebner @ 2026-03-25 19:46 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
In-Reply-To: <20260325194326.77923-2-manuelebner@mailbox.org>
cleanup and harmonize output of scripts/ver_linux and table in changes.rst
ver_linux:
fix path to changes.rst
Add missing tools in ver_linux
bash, bc, bindgen, btrfs-progs, Clang, gdb, GNU awk, GNU tar,
GRUB, GRUB2, gtags, iptables, kmod, mcelog, mkimage, openssl,
pahole, Python, Rust, Sphinx, squashfs-tools
changes.rst:
add reference to ./scripts/ver_linux
needn't -> do not need to
add gdb version 7.2 as mentioned in:
Documentation/process/debugging/gdb-kernel-debugging.rst
scripts/gdb/vmlinux-gdb.py
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/changes.rst | 14 +++++----
scripts/ver_linux | 49 ++++++++++++++++++++++---------
2 files changed, 43 insertions(+), 20 deletions(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 6b373e193548..d94503341254 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -19,12 +19,13 @@ Current Minimal Requirements
Upgrade to at **least** these software revisions before thinking you've
encountered a bug! If you're unsure what version you're currently
-running, the suggested command should tell you.
+running, the suggested command should tell you. For a list of the programs
+on your system including their version execute ./scripts/ver_linux
Again, keep in mind that this list assumes you are already functionally
running a Linux kernel. Also, not all tools are necessary on all
systems; obviously, if you don't have any PC Card hardware, for example,
-you probably needn't concern yourself with pcmciautils.
+you probably do not need to concern yourself with pcmciautils.
====================== =============== ========================================
Program Minimal version Command to check the version
@@ -40,7 +41,7 @@ flex 2.5.35 flex --version
bison 2.0 bison --version
pahole 1.22 pahole --version
util-linux 2.10o mount --version
-kmod 13 depmod -V
+kmod 13 kmod -V
e2fsprogs 1.41.4 e2fsck -V
jfsutils 1.1.3 fsck.jfs -V
xfsprogs 2.6.0 xfs_db -V
@@ -51,8 +52,8 @@ quota-tools 3.09 quota -V
PPP 2.4.0 pppd --version
nfs-utils 1.0.5 showmount --version
procps 3.2.0 ps --version
-udev 081 udevd --version
-grub 0.93 grub --version || grub-install --version
+udev 081 udevadm --version
+GRUB 0.93 grub --version || grub-install --version
mcelog 0.6 mcelog --version
iptables 1.4.2 iptables -V
openssl & libcrypto 1.0.0 openssl version
@@ -62,7 +63,8 @@ GNU tar 1.28 tar --version
gtags (optional) 6.6.5 gtags --version
mkimage (optional) 2017.01 mkimage --version
Python 3.9.x python3 --version
-GNU AWK (optional) 5.1.0 gawk --version
+GNU awk (optional) 5.1.0 gawk --version
+gdb 7.2 gdb --version
====================== =============== ========================================
.. [#f1] Sphinx is needed only to build the Kernel documentation
diff --git a/scripts/ver_linux b/scripts/ver_linux
index d6f2362d3792..fab0c68a6c52 100755
--- a/scripts/ver_linux
+++ b/scripts/ver_linux
@@ -7,7 +7,7 @@
BEGIN {
usage = "If some fields are empty or look unusual you may have an old version.\n"
- usage = usage "Compare to the current minimal requirements in Documentation/Changes.\n"
+ usage = usage "Compare to the current minimal requirements in Documentation/process/changes.rst\n"
print usage
system("uname -a")
@@ -18,22 +18,22 @@ BEGIN {
libcpp = "(libg|stdc)[+]+[.]so([.][0-9]+)+$"
printversion("GNU C", version("gcc -dumpversion"))
- printversion("GNU Make", version("make --version"))
- printversion("Binutils", version("ld -v"))
- printversion("Util-linux", version("mount --version"))
+ printversion("GNU make", version("make --version"))
+ printversion("binutils", version("ld -v"))
+ printversion("util-linux", version("mount --version"))
printversion("Mount", version("mount --version"))
printversion("Module-init-tools", version("depmod -V"))
- printversion("E2fsprogs", version("tune2fs"))
- printversion("Jfsutils", version("fsck.jfs -V"))
- printversion("Xfsprogs", version("xfs_db -V"))
- printversion("Pcmciautils", version("pccardctl -V"))
+ printversion("e2fsprogs", version("e2fsck -V"))
+ printversion("jfsutils", version("fsck.jfs -V"))
+ printversion("xfsprogs", version("xfs_db -V"))
+ printversion("pcmciautils", version("pccardctl -V"))
printversion("Pcmcia-cs", version("cardmgr -V"))
- printversion("Quota-tools", version("quota -V"))
+ printversion("quota-tools", version("quota -V"))
printversion("PPP", version("pppd --version"))
printversion("Isdn4k-utils", version("isdnctrl"))
- printversion("Nfs-utils", version("showmount --version"))
- printversion("Bison", version("bison --version"))
- printversion("Flex", version("flex --version"))
+ printversion("nfs-utils", version("showmount --version"))
+ printversion("bison", version("bison --version"))
+ printversion("flex", version("flex --version"))
while ("ldconfig -p 2>/dev/null" | getline > 0)
if ($NF ~ libc || $NF ~ libcpp)
@@ -41,13 +41,34 @@ BEGIN {
printversion("Linux C" ($NF ~ libcpp? "++" : "") " Library", ver)
printversion("Dynamic linker (ldd)", version("ldd --version"))
- printversion("Procps", version("ps --version"))
+ printversion("procps", version("ps --version"))
printversion("Net-tools", version("ifconfig --version"))
printversion("Kbd", version("loadkeys -V"))
printversion("Console-tools", version("loadkeys -V"))
printversion("Sh-utils", version("expr --v"))
- printversion("Udev", version("udevadm --version"))
+ printversion("udev", version("udevadm --version"))
printversion("Wireless-tools", version("iwconfig --version"))
+ printversion("bash", version("bash --version"))
+ printversion("bc", version("bc --version"))
+ printversion("bindgen", version("bindgen --version"))
+ printversion("btrfs-progs", version("btrfs --version"))
+ printversion("Clang", version("clang --version"))
+ printversion("gdb", version("gdb -version"))
+ printversion("GNU awk", version("gawk --version"))
+ printversion("GNU tar", version("tar --version"))
+ printversion("GRUB", version("grub-install --version"))
+ printversion("GRUB2", version("grub2-install --version"))
+ printversion("gtags", version("gtags --version"))
+ printversion("iptables", version("iptables -V"))
+ printversion("kmod", version("kmod -V"))
+ printversion("mcelog", version("mcelog --version"))
+ printversion("mkimage", version("mkimage --version"))
+ printversion("openssl", version("openssl version"))
+ printversion("pahole", version("pahole --version"))
+ printversion("Python", version("python3 -V"))
+ printversion("Rust", version("rustc --version"))
+ printversion("Sphinx", version("sphinx-build --version"))
+ printversion("squashfs-tools", version("mksquashfs -version"))
while ("sort /proc/modules" | getline > 0) {
mods = mods sep $1
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/2] workflow, scripts: sort changes.rst and ver_linux
From: Manuel Ebner @ 2026-03-25 19:43 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Manuel Ebner
restructured the patch series into logical changes.
fixed changelogs, but i'm not super content.
[v4] -> [v5]:
undo "remove (optional)" from [v4]
merged patches with same concepts
[PATCH v4 1/4], [PATCH v4 2/4] -> [PATCH v5 1/2]
[PATCH v4 3/4], [PATCH v4 4/4] -> [PATCH v5 2/2]
fix changelogs for the individual patches
[v3] -> [v4]:
split [PATCH v3 1/2] into
[PATCH v4 1/4] and
[PATCH v4 3/4]
split [PATCH v3 2/2] into
[PATCH v4 2/4] and
[PATCH v4 4/4]
make toolnames uniform in both files
make version command uniform in both files
changes.rst:
remove footnote for Sphinx
remove "(optional)"
[v2] -> [v3]:
fix changelog
changes.rst:
needn't -> do not need to
add gdb 7.2
ver_linux:
/Changes.rst -> /changes.rst
add gdb
[v1] -> [v2]:
split v1 into a patch series
changes.rst:
add reference to ver_linux
ver_linux:
fix path to changes.rst
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
^ permalink raw reply
* Re: [PATCH v4 0/4] workflow, scripts: sort changes.rst and ver_linux
From: Jonathan Corbet @ 2026-03-25 13:40 UTC (permalink / raw)
To: Manuel Ebner, Collin Funk, Shuah Khan; +Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <ce9e75d81c6bd67cb2ff92bfd63f9dea0e7980e8.camel@airmail.cc>
Manuel Ebner <manuelebner@airmail.cc> writes:
> On Tue, 2026-03-17 at 09:08 -0600, Jonathan Corbet wrote:
>> Manuel Ebner <manuelebner@airmail.cc> writes:
>>
>> > ...
>> Also, overall, I am still not thrilled about you having send me patches
>> under a false name. I need you to, at a bare minimum, acknowledge that
>> this was a violation of the trust that the kernel project depends on,
>> and that the current name you are using is the real one.
>>
>> Thanks,
>>
>> jon
>
> Hello Jon,
> unfortunately I have an issue with my e-mail provider. Because of an spamhouse.org
> entry my mails do not show up in the mailing lists.
> Do you mind me changing my e-mail address to manuelebner@mailbox.org
Use whichever address works for you, that is not a problem.
jon
^ permalink raw reply
* Re: [PATCH v4 0/4] workflow, scripts: sort changes.rst and ver_linux
From: Manuel Ebner @ 2026-03-25 13:30 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <87zf46biix.fsf@trenco.lwn.net>
On Tue, 2026-03-17 at 09:08 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@airmail.cc> writes:
>
> > ...
> Also, overall, I am still not thrilled about you having send me patches
> under a false name. I need you to, at a bare minimum, acknowledge that
> this was a violation of the trust that the kernel project depends on,
> and that the current name you are using is the real one.
>
> Thanks,
>
> jon
Hello Jon,
unfortunately I have an issue with my e-mail provider. Because of an spamhouse.org
entry my mails do not show up in the mailing lists.
Do you mind me changing my e-mail address to manuelebner@mailbox.org
Manuel
^ permalink raw reply
* Re: [PATCH v4 2/4] workflow: process/changes.rst: expand and cleanup list
From: Manuel Ebner @ 2026-03-23 17:50 UTC (permalink / raw)
To: Jonathan Corbet, Collin Funk, Shuah Khan
Cc: workflows, linux-doc, linux-kernel
In-Reply-To: <87fr5ycxao.fsf@trenco.lwn.net>
On Tue, 2026-03-17 at 09:04 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@airmail.cc> writes:
> > remove footnote for sphinx
> > in the paragraph before the list it says:
> > "Also, not all tools are necessary on all systems;
> > obviously, if you don't have any PC Card hardware, for example,
> > you probably needn't concern yourself with pcmciautils."
i understand this paragraph like this:
most or all tools can be optional, depending on the specific use case.
e.g. quota-tools is optional for people compiling the kernel.
that's why i removed the optional markings.
and pcmciautils, the example in the the file, is not marked as optional in changes.rst:
====================== =============== ========================================
Program Minimal version Command to check the version
====================== =============== ========================================
[...]
pcmciautils 004 pccardctl -V
> > remove "(optional)" for the same reason as above
>
> Here you have lost some information - now the document doesn't say
> *which* tools are optional. That is, I think, not ideal.
that's true.
my question is: what are the tools optional for?
or what is the criteria for "optional"?
Manuel
^ permalink raw reply
* Re: [PATCH] docs: Document pahole v1.26 requirement for KF_IMPLICIT_ARGS kfuncs
From: Alexei Starovoitov @ 2026-03-24 15:12 UTC (permalink / raw)
To: zhidao su, Ihor Solodrai
Cc: Jonathan Corbet, workflows, LKML, open list:DOCUMENTATION, bpf,
Shuah Khan, zhidao su
In-Reply-To: <20260324062028.2479059-1-suzhidao@xiaomi.com>
On Mon, Mar 23, 2026 at 11:22 PM zhidao su <soolaugust@gmail.com> wrote:
>
> Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole
> v1.26 or later. Without it, such kfuncs have incorrect BTF prototypes in
> vmlinux, causing BPF programs to fail with 'func_proto incompatible with
> vmlinux' error.
>
> This affects all sched_ext kfuncs (e.g. scx_bpf_create_dsq,
> scx_bpf_dispatch) and other KF_IMPLICIT_ARGS kfuncs across the kernel.
> Ubuntu 24.04 LTS ships pahole v1.25 by default, causing 23/30 sched_ext
> selftests to fail on affected systems.
I don't think that's true.
At least when implicit args were designed the goal was to avoid
pahole dependencies.
Please share exact steps to reproduce.
Updating doc is definitely not an answer.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] docs: Document pahole v1.26 requirement for KF_IMPLICIT_ARGS kfuncs
From: Jonathan Corbet @ 2026-03-24 13:43 UTC (permalink / raw)
To: zhidao su, workflows; +Cc: linux-kernel, linux-doc, bpf, Shuah Khan, zhidao su
In-Reply-To: <20260324062028.2479059-1-suzhidao@xiaomi.com>
zhidao su <soolaugust@gmail.com> writes:
> Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole
> v1.26 or later. Without it, such kfuncs have incorrect BTF prototypes in
> vmlinux, causing BPF programs to fail with 'func_proto incompatible with
> vmlinux' error.
>
> This affects all sched_ext kfuncs (e.g. scx_bpf_create_dsq,
> scx_bpf_dispatch) and other KF_IMPLICIT_ARGS kfuncs across the kernel.
> Ubuntu 24.04 LTS ships pahole v1.25 by default, causing 23/30 sched_ext
> selftests to fail on affected systems.
>
> Document this requirement in Documentation/process/changes.rst so users
> understand the failure mode and can upgrade pahole appropriately.
>
> Signed-off-by: zhidao su <suzhidao@xiaomi.com>
> ---
> Documentation/process/changes.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 6b373e193548..141a4576c24d 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -145,6 +145,11 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system
> generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel
> modules as well. This requires pahole v1.22 or later.
>
> +Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26
> +or later. Without it, such kfuncs will have incorrect BTF prototypes in
> +vmlinux, causing BPF programs to fail to load with a "func_proto incompatible
> +with vmlinux" error. Many sched_ext kfuncs are affected.
This seems like reasonable information, but is there a reason to not
just raise the minimum pahole version to 1.26 and be done with it?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Greg Kroah-Hartman @ 2026-03-24 11:45 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <acJ2gnnA9MP1wO_Z@laps>
On Tue, Mar 24, 2026 at 07:33:22AM -0400, Sasha Levin wrote:
> On Tue, Mar 24, 2026 at 09:20:01AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 23, 2026 at 07:58:50PM -0400, Sasha Levin wrote:
> > > > But this only works if the kabi stuff is built into the kernel image,
> > > > right? This doesn't work if any of these abi sections are in a module
> > > > or am I missing that logic here?
> > >
> > > That is correct, for now.
> > >
> > > I'm only trying to tackle syscalls to begin with, and since no syscalls live in
> > > modules, we have no need for module support.
> >
> > We used to support syscalls in modules, but thankfully that is now gone.
> > But, how will this work for stuff like usbfs ioctls? That is a module,
> > and our uapi is, by far, in drivers through ioctl "hell" and that would
> > be great to be able to document through all of this. Will that just not
> > be in the debugfs api?
>
> It will. I see it working just like how BTF or trace events do it now.
>
> When a module loads, find_module_sections() extracts the .kapi_specs section
> pointer and element count into new struct module fields. The COMING notifier
> then iterates those specs, registers each via the existing kapi_register_spec()
> dynamic registration path, and creates per-spec debugfs files under the
> existing /sys/kernel/debug/kapi/specs/ directory. The kapi_list_show() function
> is extended to also walk the dynamic_api_specs list (currently it only iterates
> the static __start_kapi_specs..__stop_kapi_specs range). On GOING, all specs
> owned by that module are removed from the list and their debugfs entries
> cleaned up via debugfs_remove().
Sounds good, I was worried about that static range and how that would be
"extended" or not.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Sasha Levin @ 2026-03-24 11:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026032411-paramount-lapdog-41e6@gregkh>
On Tue, Mar 24, 2026 at 09:20:01AM +0100, Greg Kroah-Hartman wrote:
>On Mon, Mar 23, 2026 at 07:58:50PM -0400, Sasha Levin wrote:
>> > But this only works if the kabi stuff is built into the kernel image,
>> > right? This doesn't work if any of these abi sections are in a module
>> > or am I missing that logic here?
>>
>> That is correct, for now.
>>
>> I'm only trying to tackle syscalls to begin with, and since no syscalls live in
>> modules, we have no need for module support.
>
>We used to support syscalls in modules, but thankfully that is now gone.
>But, how will this work for stuff like usbfs ioctls? That is a module,
>and our uapi is, by far, in drivers through ioctl "hell" and that would
>be great to be able to document through all of this. Will that just not
>be in the debugfs api?
It will. I see it working just like how BTF or trace events do it now.
When a module loads, find_module_sections() extracts the .kapi_specs section
pointer and element count into new struct module fields. The COMING notifier
then iterates those specs, registers each via the existing kapi_register_spec()
dynamic registration path, and creates per-spec debugfs files under the
existing /sys/kernel/debug/kapi/specs/ directory. The kapi_list_show() function
is extended to also walk the dynamic_api_specs list (currently it only iterates
the static __start_kapi_specs..__stop_kapi_specs range). On GOING, all specs
owned by that module are removed from the list and their debugfs entries
cleaned up via debugfs_remove().
--
Thanks,
Sasha
^ 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