From: Sasha Levin <sashal@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-api@vger.kernel.org, tools@kernel.org
Subject: Re: [RFC v3 2/4] kernel/api: enable kerneldoc-based API specifications
Date: Sun, 20 Jul 2025 22:54:31 -0400 [thread overview]
Message-ID: <aH2r55bjqqtKxOEQ@lappy> (raw)
In-Reply-To: <4777f4d7-f1c6-4345-92b2-0ba5d6563ee2@infradead.org>
On Sun, Jul 20, 2025 at 05:55:05PM -0700, Randy Dunlap wrote:
>Hi Sasha,
>
>I would like to ask a few questions to try to clarify/understand, please.
>
>On 7/11/25 4:42 AM, Sasha Levin wrote:
>> Allow kernel developers to write API specifications directly in
>> kerneldoc comments, which are automatically converted to machine-readable
>> C macros during build.
>>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>> kernel/api/Makefile | 21 +-
>> scripts/Makefile.build | 28 ++
>> scripts/generate_api_specs.sh | 59 +++
>> scripts/kernel-doc.py | 5 +
>> scripts/lib/kdoc/kdoc_apispec.py | 623 +++++++++++++++++++++++++++++++
>> scripts/lib/kdoc/kdoc_output.py | 5 +-
>> scripts/lib/kdoc/kdoc_parser.py | 54 ++-
>> 7 files changed, 791 insertions(+), 4 deletions(-)
>> create mode 100755 scripts/generate_api_specs.sh
>> create mode 100644 scripts/lib/kdoc/kdoc_apispec.py
>>
>
>[snip]
>
>> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
>> index a6461ea411f7a..5c0e44d1b6dbc 100644
>> --- a/scripts/Makefile.build
>> +++ b/scripts/Makefile.build
>> @@ -172,6 +172,34 @@ ifneq ($(KBUILD_EXTRA_WARN),)
>> $<
>> endif
>>
>> +# Generate API spec headers from kernel-doc comments
>> +ifeq ($(CONFIG_KAPI_SPEC),y)
>> +# Function to check if a file has API specifications
>> +has-apispec = $(shell grep -qE '^\s*\*\s*(api-type|long-desc|context-flags|param-type|error-code|capability|signal|lock|side-effect|state-trans):' $(src)/$(1) 2>/dev/null && echo $(1))
>> +
>> +# Get base names without directory prefix
>> +c-objs-base := $(notdir $(real-obj-y) $(real-obj-m))
>> +# Filter to only .o files with corresponding .c source files
>> +c-files := $(foreach o,$(c-objs-base),$(if $(wildcard $(src)/$(o:.o=.c)),$(o:.o=.c)))
>
>1. One must build a kernel (with some desired .config file) to use/test this,
>correct?
Mostly yes, but another option is to use the kapi tool (which I haven't
updated and sent out as part of v3, but you can see it in v2:
https://lore.kernel.org/tools/20250624180742.5795-23-sashal@kernel.org/T/#u).
With the kapi tool, you can also run it on a source tree to extract the
same information that you'd have in a built vmlinux.
>2. It looks like it only checks .c files, omitting header files. (?)
>Some APIs are only present in header files (e.g., all of <linux/list.h> is
>either macros or inline functions).
I was trying to focus on the userspace side of things, so I didn't think
we'll have anything in header files, but I also don't have an objection
to extending it to scan headers too.
>> +# Also check for any additional .c files that contain API specs but are included
>> +extra-c-files := $(shell find $(src) -maxdepth 1 -name "*.c" -exec grep -l '^\s*\*\s*\(api-type\|long-desc\|context-flags\|param-type\|error-code\|capability\|signal\|lock\|side-effect\|state-trans\):' {} \; 2>/dev/null | xargs -r basename -a)
>
>3a. included files: does this catch the (rare) use of a C file doing
>#include <path to some other C file> ?
Yes!
Jon suggested I apply this to a kernel/sched/ syscall to see how it
handles complex syscalls, but it also added another complexity because
sched does exactly what you described (kernel/sched/build_policy.c
includes a bunch of other .c files including syscalls.c). See the 4th
patch in the series.
>3b. Quite a few makefiles generate final .o files with a different name
>from the source files. It looks like that is handled above by looking
>for the first (or intermediate) .o file for each .c file, so the final
>.o file with a different name is ignored (or at least doesn't come into
>play here). Yes?
Yes, exactly. The code looks for .o files that have directly
corresponding .c files with the same base name. When makefiles generate
final .o files with different names (like when multiple .c files are
combined into a single .o, or when the output name is changed), those
renamed .o files won't have a matching .c file and will be filtered out
by the $(if $(wildcard $(src)/$(o:.o=.c)),$(o:.o=.c)) check.
>Thanks.
Thanks for looking into it!
--
Thanks,
Sasha
next prev parent reply other threads:[~2025-07-21 2:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 11:42 [RFC v3 0/4] Kernel API Specification Framework with kerneldoc integration Sasha Levin
2025-07-11 11:42 ` [RFC v3 1/4] kernel/api: introduce kernel API specification framework Sasha Levin
2025-07-16 7:21 ` Askar Safin
2025-08-01 13:53 ` Sasha Levin
2025-07-11 11:42 ` [RFC v3 2/4] kernel/api: enable kerneldoc-based API specifications Sasha Levin
2025-07-21 0:55 ` Randy Dunlap
2025-07-21 2:54 ` Sasha Levin [this message]
2025-07-21 3:17 ` Randy Dunlap
2025-07-11 11:42 ` [RFC v3 3/4] mm/mlock: add API specification for mlock Sasha Levin
2025-07-11 11:42 ` [RFC v3 4/4] kernel/sched: add specs for sys_sched_setattr() Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aH2r55bjqqtKxOEQ@lappy \
--to=sashal@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=tools@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).