Message-ID: <20260111121151.39801d8d@fedora>
Date: Sun, 11 Jan 2026 12:11:51 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Theodore Tso" <tytso@....edu>
Cc: "Paul E. McKenney" <paulmck@...nel.org>, "Dr. David Alan Gilbert"
 <dave@...blig.org>, Julia Lawall <julia.lawall@...ia.fr>, Sasha Levin
 <sashal@...nel.org>, Gabriele Paoloni <gpaoloni@...hat.com>, Kate Stewart
 <kstewart@...uxfoundation.org>, Chuck Wolber <chuckwolber@...il.com>,
 Dmitry Vyukov <dvyukov@...gle.com>, Mark Rutland <mark.rutland@....com>,
 Thomas Gleixner <tglx@...utronix.de>, Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>, Shuah Khan <skhan@...uxfoundation.org>, Chris
 Mason <clm@...a.com>, linux-kernel@...r.kernel.org
Subject: Re: Follow-up on Linux-kernel code accessibility

On Sat, 10 Jan 2026 19:30:40 -0800
"Theodore Tso" <tytso@....edu> wrote:
> 
> Steven, you may disagree with this conclusion, but speaking
> personally, everything that I've read on this thread strongly confirms
> it.

I'm not talking about someone with no knowledge about the kernel. If
someone has a strong understanding of how an operating system works,
and a general idea of the system, looking at the comments in the code
should be enough for them to figure out the understanding of what is
happening.

I look at it as two levels. There's an architectural understanding
(which is achieved via books and design documents and such) and then
there's the implementation details. The implementation details should
be expressed in comments, and actually avoided when possible from the
design and architectural documentation. That's because the
implementation can change, and does often.

> 
> I am not sure that we can count on LLM's to provide reliable "active
> software assistance", although a recent experiment, where I enabled
> Gemini 3's "deep research" mode, and asked it the question, "How much
> money do most software engineers need to retire?", resulted in a 15
> page report[2], with footnotes, so you could verify whether or not the
> LLM was halucinating or not --- and it was much better than I
> expected.  I'm not sure I agree with all of it, but it's better than
> many of the YouTube financial advice videos out there.  :-)
> 
> [2] https://docs.google.com/document/d/1EDqC-qnHkEyEeewXFx4PuL4VtnC_LxPZ2CKlleB7QBc/edit?tab=t.0

I fail to understand the analogy of using AI for financial security for
retired software engineers and understanding an implementation of code
by experience developers.

If I hit a bug that leads me to RCU code, I would hope there's enough
commenting for me to understand if the bug is with RCU or my usage of
RCU.

> 
> Thta being said, there's a big difference between retirement planning
> and trusting a LLM to be able to explain the finer points of say, an
> I/O scheduler, the MM's OOM Killer hueristics, or RCU.  I suspect
> there are no silver bullets here.

There was a performance issue that Joel pointed out which lead to this
one function I was looking at. But with the use of various constants
that don't appear to be documented anywhere made it impossible for me
to know if that code really was the performance issue or not. Sure I
could simply ask Paul or Joel why is 3 so important here, but the fact
I need to ask is a fail in my mind.

I have the same issue with the scheduler. There's parts of the
scheduler that I worked on years ago, but the changes to it, I have no
idea why it's doing what it is doing because there's no comments about
it. The design is basically the same, but the implementation has
changed. I'm going to be actively fixing that, as one of my OKRs is to
comment the scheduler in more detail as to explain why functions do
what they do.

-- Steve

Powered by blists - more mailing lists