Re: Follow-up on Linux-kernel code accessibility

[Sasha Levin <sashal@kernel.org>]

On Fri, Dec 19, 2025 at 12:09:45PM -0500, Theodore Tso wrote:
>On Fri, Dec 19, 2025 at 07:51:47AM +0100, Julia Lawall wrote:
>> automatically in many cases, or regenerated automatically from some hints.
>> But the low-level ones may be needed to make the bridge between the code
>> and the high-level specification.
>
>Sasha's API specification framework patches might be something that's
>worth considering in this context.  The thing that we need be careful
>though, is that we might need to have a way of tagging kernel
>functions in terms of the priority for the first set of high-level
>interfaces for a newcomer to the kernel should look at first, and
>those that might be less important, so that the newcomer won't get
>overwhelmed with a vast number of low-level definitions.

I just sent a refreshed version earlier today
(https://lore.kernel.org/all/20251218204239.4159453-1-sashal@kernel.org/),
which also links to a branch that has over 100 LLM-generated syscall specs.

The nice thing about it is that we don't need to trust the LLM to do the right
thing: the spec is machine readable and we can generate testing based off of
it. Running something like LTP using those specs is pretty good at highlighting
issues - whether in the spec or the actual implementation.

I'd we weary to see complex specs in kernel-internal functions. Those often get
refactored and improved. Having complex speccing on them will make that work
much more difficult and complex.

-- 
Thanks,
Sasha