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
