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
