Re: [RFC PATCH v2 0/3] Add testable code specifications

[Chuck Wolber <chuckwolber@gmail.com>]

On Wed, Oct 22, 2025 at 5:13 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Oct 22, 2025 at 04:06:10PM +0200, Gabriele Paoloni wrote:
> > > Every in-kernel api documented in a "formal" way like this?  Or a subset?
> > > If a subset, which ones specifically?  How many?  And who is going to do
> > > that?  And who is going to maintain it?  And most importantly, why is it
> > > needed at all?

I appreciate the questions. I sense there may be some confusion over who this
is intended to benefit.

The design of the Linux kernel is emergent. This is a fundamental property of
the way it is developed, and the source of its greatest strength. But it has
some shortcomings that place a burden on kernel maintainers, all kernel
testing, and even people who wish to contribute.

We intend this as a tool to address those areas.


> > > For some reason Linux has succeeded in pretty much every place an
> > > operating system is needed for cpus that it can run on (zephyr for those
> > > others that it can not.)  So why are we suddenly now, after many decades,
> > > requiring basic user/kernel stuff to be formally documented like this?

You are correct, the kernel has succeeded over many decades, and will continue
succeeding for many decades to come.

With the exception of some very narrow situations, the emergent design (or
"nuanced complexity" if you prefer that term) of the Linux kernel is not
communicated in a broadly consistent way. This affects the way the kernel is
tested, and also the way it is developed. Even veteran kernel maintainers are
tripping over nuance and complexity.


> > Let me try to answer starting from the "why".
>
> Let's ignore the "why" for now, and get to the "how" and "what" which you
> skipped from my questions above.
>
> _Exactly_ how many in-kernel functions are you claiming is needed to be
> documented in this type of way before Linux would become "acceptable" to
> these regulatory agencies, and which ones _specifically_ are they?

Exactly zero. This is not for regulators.


> Without knowing that, we could argue about the format all day long, and
> yet have nothing to show for it.

As this is not intended for regulators, it is not clear to me that catering to
their desires would be a good use of anyone's time.

I say this as a software engineer who works in a _highly_ regulated industry,
and who knows the relevant regulations quite well. There are good ideas buried
in those regulations, but (in their default form) they are _not_ appropriate
for the Linux kernel development process.


> And then, I have to ask, exactly "who" is going to do that work.

The intent is to allow for a separate maintainer path. There is more to it than
that, but I do not want to bury the lede here.


> I'll point at another "you must do this for reasons" type of request we have
> had in the past, SPDX.  Sadly that task was never actually finished as it
> looks like no one really cared to do the real work involved.  We got other
> benefits out of that effort, but the "goal" that people started that effort
> with was never met.  Part of that is me not pushing back hard enough on the
> "who is going to do the work" part of that question, which is important in
> stuff like this.

Well, I am sorry for that. I am not quite sure how to respond, but I certainly
sympathize with past frustrations. I have plenty of my own.

We are not offering a silver bullet here, and the work to describe the kernel's
design will be finished when the work of development is finished. This is just
an attempt to fill in a semantic gap that is responsible for a great deal of
technical debt and maintainer burnout.


> If you never complete the effort, your end goal of passing Linux off to those
> customers will never happen.

It is not clear to me what customers you are talking about. That is certainly
not a goal in the mind of anyone working on this project that I am aware of.


> So, try to answer that, with lots and lots of specifics, and then, if we
> agree that it is a sane thing to attempt (i.e. you are going to do all the
> work and it actually would be possible to complete), then we can argue about
> the format of the text :)

I respect what you are saying here, and perhaps the point of confusion came
from the safety related source? As is often the case in science and
engineering, we are borrowing (and _heavily_ modifying) a technique that is
found in a different domain.

The intent is to target technical debt and maintainer burnout by filling in a
semantic gap that occurs when a human idea is turned into code. Ironically,
this is why the safety regulations were written in the first place, but little
consideration was given to development methodology during that process.

Thank you,

..Ch:W..