[PATCH 0/9] Kernel API Specification Framework

Sasha Levin posted 9 patches 3 weeks, 3 days ago
There is a newer version of this series
.gitignore                                    |    1 +
Documentation/dev-tools/index.rst             |    1 +
Documentation/dev-tools/kernel-api-spec.rst   |  629 +++++++
MAINTAINERS                                   |   12 +
arch/x86/include/asm/syscall_wrapper.h        |   40 +
fs/open.c                                     |  576 +++++-
fs/read_write.c                               |  687 +++++++
include/asm-generic/vmlinux.lds.h             |   28 +
include/linux/kernel_api_spec.h               | 1580 +++++++++++++++++
include/linux/syscall_api_spec.h              |  192 ++
include/linux/syscalls.h                      |   39 +
init/Kconfig                                  |    2 +
kernel/Makefile                               |    3 +
kernel/api/.gitignore                         |    2 +
kernel/api/Kconfig                            |   70 +
kernel/api/Makefile                           |   14 +
kernel/api/kapi_debugfs.c                     |  503 ++++++
kernel/api/kapi_kunit.c                       |  536 ++++++
kernel/api/kernel_api_spec.c                  | 1277 +++++++++++++
scripts/Makefile.build                        |   31 +
scripts/Makefile.clean                        |    3 +
tools/docs/kernel-doc                         |    5 +
tools/kapi/.gitignore                         |    4 +
tools/kapi/Cargo.toml                         |   19 +
tools/kapi/src/extractor/debugfs.rs           |  581 ++++++
tools/kapi/src/extractor/kerneldoc_parser.rs  | 1554 ++++++++++++++++
tools/kapi/src/extractor/mod.rs               |  463 +++++
tools/kapi/src/extractor/source_parser.rs     |  405 +++++
.../src/extractor/vmlinux/binary_utils.rs     |  505 ++++++
.../src/extractor/vmlinux/magic_finder.rs     |  112 ++
tools/kapi/src/extractor/vmlinux/mod.rs       |  842 +++++++++
tools/kapi/src/formatter/json.rs              |  727 ++++++++
tools/kapi/src/formatter/mod.rs               |  140 ++
tools/kapi/src/formatter/plain.rs             |  708 ++++++++
tools/kapi/src/formatter/rst.rs               |  852 +++++++++
tools/kapi/src/main.rs                        |  119 ++
tools/lib/python/kdoc/kdoc_apispec.py         |  887 +++++++++
tools/lib/python/kdoc/kdoc_output.py          |    9 +-
tools/lib/python/kdoc/kdoc_parser.py          |   86 +-
tools/testing/selftests/kapi/Makefile         |    7 +
tools/testing/selftests/kapi/kapi_test_util.h |   31 +
tools/testing/selftests/kapi/test_kapi.c      | 1021 +++++++++++
42 files changed, 15294 insertions(+), 9 deletions(-)
create mode 100644 Documentation/dev-tools/kernel-api-spec.rst
create mode 100644 include/linux/kernel_api_spec.h
create mode 100644 include/linux/syscall_api_spec.h
create mode 100644 kernel/api/.gitignore
create mode 100644 kernel/api/Kconfig
create mode 100644 kernel/api/Makefile
create mode 100644 kernel/api/kapi_debugfs.c
create mode 100644 kernel/api/kapi_kunit.c
create mode 100644 kernel/api/kernel_api_spec.c
create mode 100644 tools/kapi/.gitignore
create mode 100644 tools/kapi/Cargo.toml
create mode 100644 tools/kapi/src/extractor/debugfs.rs
create mode 100644 tools/kapi/src/extractor/kerneldoc_parser.rs
create mode 100644 tools/kapi/src/extractor/mod.rs
create mode 100644 tools/kapi/src/extractor/source_parser.rs
create mode 100644 tools/kapi/src/extractor/vmlinux/binary_utils.rs
create mode 100644 tools/kapi/src/extractor/vmlinux/magic_finder.rs
create mode 100644 tools/kapi/src/extractor/vmlinux/mod.rs
create mode 100644 tools/kapi/src/formatter/json.rs
create mode 100644 tools/kapi/src/formatter/mod.rs
create mode 100644 tools/kapi/src/formatter/plain.rs
create mode 100644 tools/kapi/src/formatter/rst.rs
create mode 100644 tools/kapi/src/main.rs
create mode 100644 tools/lib/python/kdoc/kdoc_apispec.py
create mode 100644 tools/testing/selftests/kapi/Makefile
create mode 100644 tools/testing/selftests/kapi/kapi_test_util.h
create mode 100644 tools/testing/selftests/kapi/test_kapi.c
[PATCH 0/9] Kernel API Specification Framework
Posted by Sasha Levin 3 weeks, 3 days ago
This proposal introduces machinery for documenting kernel APIs, addressing the
long-standing challenge of maintaining stable interfaces between the kernel and
user-space programs. Despite the kernel's commitment to never breaking user
space, the lack of machine-readable API specifications has led to breakages and
across system calls and IOCTLs.

Specifications can document parameter types, valid ranges, constraints, and
alignment requirements. They capture return value semantics including success
conditions and error codes with their meaning. Execution context requirements,
capabilities, locking constraints, signal handling behavior, and side effects
can all be formally specified.

These specifications live alongside the code they document and are both
human-readable and machine-parseable. They can be validated at runtime when
CONFIG_KAPI_RUNTIME_CHECKS is enabled, exported via debugfs for userspace
tools, and extracted from either vmlinux or source code.

This enables static analysis tools to verify userspace API usage at compile
time, test generation based on formal specifications, consistent error handling
validation, automated documentation generation, and formal verification of
kernel interfaces.

The implementation includes a core framework with ELF section storage,
kerneldoc integration for inline specification, a debugfs interface for runtime
querying, and a Rust-based extraction tool (tools/kapi) supporting JSON, RST,
and plain text output formats. Example specifications are provided for the four
fundamental file syscalls (sys_open, sys_close, sys_read, sys_write). The
series also includes a KUnit test suite with 38 tests and a runtime
verification selftest with 29+ TAP tests.

The series with runtime testing enabled (CONFIG_KAPI_RUNTIME_CHECKS=y)
currently survives LTP tests in a KVM VM.

Changes since RFC v5:

- Streamlined example specs: focus on open/close/read/write to start with.

- Added KUnit test suite.

- Added runtime verification selftest.

- Fixed kernel test robot warnings from v5: fixed "document isn't included in
  any toctree" (kernel-api-spec.rst now properly added to
  Documentation/dev-tools/index.rst), fixed sparse "non size-preserving
  integer to pointer cast" warnings in kernel_api_spec.c.

- Rebased on v7.0-rc1.

References:

  RFC v5: https://lore.kernel.org/lkml/20251218204239.4159453-1-sashal@kernel.org/
  RFC v4: https://lore.kernel.org/lkml/20250825181434.3340805-1-sashal@kernel.org/
  RFC v3: https://lore.kernel.org/lkml/20250711114248.2288591-1-sashal@kernel.org/
  RFC v2: https://lore.kernel.org/lkml/20250624180742.5795-1-sashal@kernel.org/
  RFC v1: https://lore.kernel.org/lkml/20250614134858.790460-1-sashal@kernel.org/

Sasha Levin (9):
  kernel/api: introduce kernel API specification framework
  kernel/api: enable kerneldoc-based API specifications
  kernel/api: add debugfs interface for kernel API specifications
  tools/kapi: Add kernel API specification extraction tool
  kernel/api: add API specification for sys_open
  kernel/api: add API specification for sys_close
  kernel/api: add API specification for sys_read
  kernel/api: add API specification for sys_write
  kernel/api: add runtime verification selftest

 .gitignore                                    |    1 +
 Documentation/dev-tools/index.rst             |    1 +
 Documentation/dev-tools/kernel-api-spec.rst   |  629 +++++++
 MAINTAINERS                                   |   12 +
 arch/x86/include/asm/syscall_wrapper.h        |   40 +
 fs/open.c                                     |  576 +++++-
 fs/read_write.c                               |  687 +++++++
 include/asm-generic/vmlinux.lds.h             |   28 +
 include/linux/kernel_api_spec.h               | 1580 +++++++++++++++++
 include/linux/syscall_api_spec.h              |  192 ++
 include/linux/syscalls.h                      |   39 +
 init/Kconfig                                  |    2 +
 kernel/Makefile                               |    3 +
 kernel/api/.gitignore                         |    2 +
 kernel/api/Kconfig                            |   70 +
 kernel/api/Makefile                           |   14 +
 kernel/api/kapi_debugfs.c                     |  503 ++++++
 kernel/api/kapi_kunit.c                       |  536 ++++++
 kernel/api/kernel_api_spec.c                  | 1277 +++++++++++++
 scripts/Makefile.build                        |   31 +
 scripts/Makefile.clean                        |    3 +
 tools/docs/kernel-doc                         |    5 +
 tools/kapi/.gitignore                         |    4 +
 tools/kapi/Cargo.toml                         |   19 +
 tools/kapi/src/extractor/debugfs.rs           |  581 ++++++
 tools/kapi/src/extractor/kerneldoc_parser.rs  | 1554 ++++++++++++++++
 tools/kapi/src/extractor/mod.rs               |  463 +++++
 tools/kapi/src/extractor/source_parser.rs     |  405 +++++
 .../src/extractor/vmlinux/binary_utils.rs     |  505 ++++++
 .../src/extractor/vmlinux/magic_finder.rs     |  112 ++
 tools/kapi/src/extractor/vmlinux/mod.rs       |  842 +++++++++
 tools/kapi/src/formatter/json.rs              |  727 ++++++++
 tools/kapi/src/formatter/mod.rs               |  140 ++
 tools/kapi/src/formatter/plain.rs             |  708 ++++++++
 tools/kapi/src/formatter/rst.rs               |  852 +++++++++
 tools/kapi/src/main.rs                        |  119 ++
 tools/lib/python/kdoc/kdoc_apispec.py         |  887 +++++++++
 tools/lib/python/kdoc/kdoc_output.py          |    9 +-
 tools/lib/python/kdoc/kdoc_parser.py          |   86 +-
 tools/testing/selftests/kapi/Makefile         |    7 +
 tools/testing/selftests/kapi/kapi_test_util.h |   31 +
 tools/testing/selftests/kapi/test_kapi.c      | 1021 +++++++++++
 42 files changed, 15294 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/dev-tools/kernel-api-spec.rst
 create mode 100644 include/linux/kernel_api_spec.h
 create mode 100644 include/linux/syscall_api_spec.h
 create mode 100644 kernel/api/.gitignore
 create mode 100644 kernel/api/Kconfig
 create mode 100644 kernel/api/Makefile
 create mode 100644 kernel/api/kapi_debugfs.c
 create mode 100644 kernel/api/kapi_kunit.c
 create mode 100644 kernel/api/kernel_api_spec.c
 create mode 100644 tools/kapi/.gitignore
 create mode 100644 tools/kapi/Cargo.toml
 create mode 100644 tools/kapi/src/extractor/debugfs.rs
 create mode 100644 tools/kapi/src/extractor/kerneldoc_parser.rs
 create mode 100644 tools/kapi/src/extractor/mod.rs
 create mode 100644 tools/kapi/src/extractor/source_parser.rs
 create mode 100644 tools/kapi/src/extractor/vmlinux/binary_utils.rs
 create mode 100644 tools/kapi/src/extractor/vmlinux/magic_finder.rs
 create mode 100644 tools/kapi/src/extractor/vmlinux/mod.rs
 create mode 100644 tools/kapi/src/formatter/json.rs
 create mode 100644 tools/kapi/src/formatter/mod.rs
 create mode 100644 tools/kapi/src/formatter/plain.rs
 create mode 100644 tools/kapi/src/formatter/rst.rs
 create mode 100644 tools/kapi/src/main.rs
 create mode 100644 tools/lib/python/kdoc/kdoc_apispec.py
 create mode 100644 tools/testing/selftests/kapi/Makefile
 create mode 100644 tools/testing/selftests/kapi/kapi_test_util.h
 create mode 100644 tools/testing/selftests/kapi/test_kapi.c

-- 
2.51.0
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Jakub Kicinski 3 weeks, 2 days ago
On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> This enables static analysis tools to verify userspace API usage at compile
> time, test generation based on formal specifications, consistent error handling
> validation, automated documentation generation, and formal verification of
> kernel interfaces.

Could you give some examples? We have machine readable descriptions for
Netlink interfaces, we approached syzbot folks and they did not really
seem to care for those.
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Dmitry Vyukov 3 weeks, 1 day ago
On Sat, 14 Mar 2026 at 19:18, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> > This enables static analysis tools to verify userspace API usage at compile
> > time, test generation based on formal specifications, consistent error handling
> > validation, automated documentation generation, and formal verification of
> > kernel interfaces.
>
> Could you give some examples? We have machine readable descriptions for
> Netlink interfaces, we approached syzbot folks and they did not really
> seem to care for those.

I think our reasoning wrt syzkaller was that not all interfaces in all
relevant kernels are described with netlink yml descriptions, so we
need to continue using the extraction of interfaces from the source
code. And if we have that code, then using yml as an additional data
source only adds code/complexity. Additionally, we may extract some
extra constraints/info from code that are not present in yml.

Realistically system call descriptions may have the same problem for
us at this point, since we extract lots of info from the source code
already:
https://raw.githubusercontent.com/google/syzkaller/refs/heads/master/sys/linux/auto.txt
(and LLMs obviously can allow us to extract more)
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Jakub Kicinski 3 weeks ago
On Mon, 16 Mar 2026 08:05:53 +0100 Dmitry Vyukov wrote:
> On Sat, 14 Mar 2026 at 19:18, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:  
> > > This enables static analysis tools to verify userspace API usage at compile
> > > time, test generation based on formal specifications, consistent error handling
> > > validation, automated documentation generation, and formal verification of
> > > kernel interfaces.  
> >
> > Could you give some examples? We have machine readable descriptions for
> > Netlink interfaces, we approached syzbot folks and they did not really
> > seem to care for those.  
> 
> I think our reasoning wrt syzkaller was that not all interfaces in all
> relevant kernels are described with netlink yml descriptions, so we
> need to continue using the extraction of interfaces from the source
> code. And if we have that code, then using yml as an additional data
> source only adds code/complexity. Additionally, we may extract some
> extra constraints/info from code that are not present in yml.
> 
> Realistically system call descriptions may have the same problem for
> us at this point, since we extract lots of info from the source code
> already:
> https://raw.githubusercontent.com/google/syzkaller/refs/heads/master/sys/linux/auto.txt

yup! we haven't tried to make the yml spec super useful to syzbot 
to be fair. I'm just flagging that example because in our case we
quickly went from "this will obviously be useful to syzbot" to
"although we could, it may not be super practical"

> (and LLMs obviously can allow us to extract more)

Didn't even think of that. LLMs should make short work of this sort of
extraction of information from source code..
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Sasha Levin 3 weeks ago
On Mon, Mar 16, 2026 at 03:57:56PM -0700, Jakub Kicinski wrote:
>Didn't even think of that. LLMs should make short work of this sort of
>extraction of information from source code..

This is the primary reason that this proposal resurfaced :)

I've originally proposed[1] something like this almost a decade ago, but when I
started trying to write the actual specs I hit a brick wall: it was simply not
tractable.

With LLMs, writing the specs is something we can actually pull off, and we can
verify their correctness so LLMs don't get to hallucinate.

The specs you see in the following patches are all LLM generated.

-- 
Thanks,
Sasha
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Sasha Levin 3 weeks, 2 days ago
On Sat, Mar 14, 2026 at 11:18:22AM -0700, Jakub Kicinski wrote:
>On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
>> This enables static analysis tools to verify userspace API usage at compile
>> time, test generation based on formal specifications, consistent error handling
>> validation, automated documentation generation, and formal verification of
>> kernel interfaces.
>
>Could you give some examples? We have machine readable descriptions for
>Netlink interfaces, we approached syzbot folks and they did not really
>seem to care for those.

Once the API is in a machine-readable format, we can write formatters to
output whatever downstream tools need. The kapi tool in the series
already ships with plain text, JSON, and RST formatters, and adding new
output formats is straightforward. We don't need to convince the
syzkaller folks to consume our specs, we can just output them in a
format that syzkaller already understands.

For example, I have a syzlang formatter that produces the following
from the sys_read spec in this series:

   # --- read ---
   # Read data from a file descriptor
   #
   # @context process, sleepable
   #
   # @capability CAP_DAC_OVERRIDE: Bypass discretionary access control on read permission
   # @capability CAP_DAC_READ_SEARCH: Bypass read permission checks on regular files
   #
   # @error EPERM (-1): Returned by fanotify permission events...
   # @error EINTR (-4): The call was interrupted by a signal before any data was read.
   # @error EIO (-5): A low-level I/O error occurred.
   # @error EBADF (-9): fd is not a valid file descriptor, or fd was not opened for reading.
   # @error EAGAIN (-11): O_NONBLOCK set and read would block.
   # @error EACCES (-13): LSM denied the read operation via security_file_permission().
   # @error EFAULT (-14): buf points outside the accessible address space.
   # @error EISDIR (-21): fd refers to a directory.
   # @error EINVAL (-22): fd not suitable for reading, O_DIRECT misaligned, count negative...
   # @error ENODATA (-61): Data not available in cache...
   # @error EOVERFLOW (-75): File position plus count would exceed LLONG_MAX.
   # @error EOPNOTSUPP (-95): Read not supported for this file type...
   # @error ENOBUFS (-105): Buffer too small for complete notification...
   #
   # @constraint MAX_RW_COUNT: actual_count = min(count, MAX_RW_COUNT)
   # @constraint File must be open for reading: (file->f_mode & FMODE_READ) && (file->f_mode & FMODE_CAN_READ)
   #
   # @signal Any signal: restartable, error=-4
   #
   # @lock file->f_pos_lock (mutex, internal): For seekable files with FMODE_ATOMIC_POS
   # @lock Filesystem-specific locks (rwlock, internal)
   # @lock RCU read-side (rwlock, internal): File descriptor lookup protection
   #
   # @side-effect file->f_pos: f_pos advanced by bytes read [conditional, irreversible]
   # @side-effect inode access time: atime updated unless O_NOATIME [conditional, irreversible]
   # @side-effect task I/O accounting: rchar and syscr updated [conditional, irreversible]
   # @side-effect fsnotify events: FS_ACCESS event generated [conditional, irreversible]
   #
   # @return ssize_t: bytes read on success, negative errno on error
   #
   read(fd fd, buf ptr[out, buffer[out]], count len[buf]) intptr

That said, I don't have a strong end-to-end example with the 4 syscalls
proposed here, as open/close/read/write don't take complex structures,
and the subsystems underneath them aren't specced yet. The value becomes
clearer with richer interfaces where the gap between "we know the type
signature" and "we know the full behavioral contract" is much wider.

-- 
Thanks,
Sasha
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Mauro Carvalho Chehab 2 weeks, 6 days ago
On Sun, 15 Mar 2026 02:36:51 -0400
Sasha Levin <sashal@kernel.org> wrote:

> On Sat, Mar 14, 2026 at 11:18:22AM -0700, Jakub Kicinski wrote:
> >On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:  
> >> This enables static analysis tools to verify userspace API usage at compile
> >> time, test generation based on formal specifications, consistent error handling
> >> validation, automated documentation generation, and formal verification of
> >> kernel interfaces.  
> >
> >Could you give some examples? We have machine readable descriptions for
> >Netlink interfaces, we approached syzbot folks and they did not really
> >seem to care for those.  
> 
> Once the API is in a machine-readable format, we can write formatters to
> output whatever downstream tools need. 

Kernel-doc already does that. The way it works is that it handles 
kernel-doc markups on two steps:

- first step: parse kernel-doc markups, function prototypes and data
  types for variables, typedefs, structs, unions, enums.

  This is done inside tools/lib/python/kdoc/kdoc_parser.py.

  The documentation is stored in memory as a list of documentation
  entries. Each element there belongs to class KdocItem.

  It is trivial to output its content in JSON or YAML format. I
  submitted a path series a while ago doing exactly that, aiming to help
  writing unittests for first step:

	https://lore.kernel.org/linux-doc/7648cb5f5a1b501d9ae9a57b4d8dbeb7273d9097.1770128540.git.mchehab+huawei@kernel.org/

  I'm planing to rebase such patch series on the top of my latest
  kernel-doc patch series.

- second step: output generation. There is an abstract class named
  OutputFormat which contains the following output methods:

    def out_doc(self, fname, name, args):
        """Outputs a DOC block."""

    def out_function(self, fname, name, args):
        """Outputs a function."""

    def out_enum(self, fname, name, args):
        """Outputs an enum."""

    def out_var(self, fname, name, args):
        """Outputs a variable."""

    def out_typedef(self, fname, name, args):
        """Outputs a typedef."""

    def out_struct(self, fname, name, args):
        """Outputs a struct."""

  Producing a different output is as easy as doing:

	class MyFormat(OutputFormat):
	...
	    def out_var(self, fname, name, args):
        	self.data =+ f"whatever {name}"
	...


Thanks,
Mauro
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Sasha Levin 2 weeks, 5 days ago
On Wed, Mar 18, 2026 at 07:24:10AM +0100, Mauro Carvalho Chehab wrote:
>On Sun, 15 Mar 2026 02:36:51 -0400
>Sasha Levin <sashal@kernel.org> wrote:
>
>> On Sat, Mar 14, 2026 at 11:18:22AM -0700, Jakub Kicinski wrote:
>> >On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
>> >> This enables static analysis tools to verify userspace API usage at compile
>> >> time, test generation based on formal specifications, consistent error handling
>> >> validation, automated documentation generation, and formal verification of
>> >> kernel interfaces.
>> >
>> >Could you give some examples? We have machine readable descriptions for
>> >Netlink interfaces, we approached syzbot folks and they did not really
>> >seem to care for those.
>>
>> Once the API is in a machine-readable format, we can write formatters to
>> output whatever downstream tools need.
>
>Kernel-doc already does that. The way it works is that it handles
>kernel-doc markups on two steps:

Cool, I'll take a look. We could throw away the source parser in the kapi tool
and just use the kerneldoc parse.

-- 
Thanks,
Sasha
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by David Laight 3 weeks, 2 days ago
On Sat, 14 Mar 2026 11:18:22 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> > This enables static analysis tools to verify userspace API usage at compile
> > time, test generation based on formal specifications, consistent error handling
> > validation, automated documentation generation, and formal verification of
> > kernel interfaces.  
> 
> Could you give some examples? We have machine readable descriptions for
> Netlink interfaces, we approached syzbot folks and they did not really
> seem to care for those.

The whole thing reminds me of doxygen comment blocks.
They tend to make it hard to read the source files, hard to search
the source files (due to all the extra matches) and are pretty much
always out of date.

The kerndoc comment blocks for trivial helper functions are hard enough
to keep up to date.

The only way even parameter descriptions are going to stay correct is if the
compiler is using the definition and only the comment part is extra.
For error returns you'll need the documentation to be at the return site.

	David
Re: [PATCH 0/9] Kernel API Specification Framework
Posted by Sasha Levin 3 weeks, 2 days ago
On Sat, Mar 14, 2026 at 10:44:35PM +0000, David Laight wrote:
>On Sat, 14 Mar 2026 11:18:22 -0700
>Jakub Kicinski <kuba@kernel.org> wrote:
>
>> On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
>> > This enables static analysis tools to verify userspace API usage at compile
>> > time, test generation based on formal specifications, consistent error handling
>> > validation, automated documentation generation, and formal verification of
>> > kernel interfaces.
>>
>> Could you give some examples? We have machine readable descriptions for
>> Netlink interfaces, we approached syzbot folks and they did not really
>> seem to care for those.
>
>The whole thing reminds me of doxygen comment blocks.
>They tend to make it hard to read the source files, hard to search
>the source files (due to all the extra matches) and are pretty much
>always out of date.
>
>The kerndoc comment blocks for trivial helper functions are hard enough
>to keep up to date.
>
>The only way even parameter descriptions are going to stay correct is if the
>compiler is using the definition and only the comment part is extra.
>For error returns you'll need the documentation to be at the return site.

When CONFIG_KAPI_RUNTIME_CHECKS is enabled, the specs are enforced at
the syscall boundary. The SYSCALL_DEFINEx macro grows a wrapper that
calls kapi_validate_syscall_params() before the real implementation and
kapi_validate_syscall_return() after it. Parameter constraints (ranges,
valid flag masks, alignment) are checked on every syscall entry, and
return values are validated against the documented success/error ranges
on every exit.

If a spec goes stale, it has runtime consequences. A new flag bit added
without updating the spec's valid_mask means callers using that flag get
EINVAL, which any test exercising that path catches immediately. An
implementation returning an undocumented error code triggers a warning
from the return validation.

The selftest in the series (tools/testing/selftests/kapi/test_kapi.c)
exercises this with real syscalls, both valid and invalid inputs,
verifying the validation layer catches violations.

-- 
Thanks,
Sasha