From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD746346AE3 for ; Sun, 11 Jan 2026 17:12:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768151526; cv=none; b=SE19UX4EiMbUw9Un5TFbvAP3wh/0s40VQLzM5B9H3o3OgCWlM+CqaKsxXItZuq39NN9N5siR+BIHqPHJGaJRbaxgGv0wRuOsZxl9qTipUxv0OttmAvT1mfbETzlae/zD/+EXyZFjU6g66jB8JtIeQgUo5x9rJFzayVOkmPY+syg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768151526; c=relaxed/simple; bh=0MCcsm4qAhdmxU4KLXbB8shDrzu1pLSbP0/dv9o5CqA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NhVPKnzkx/sEHstAE69pkdtZ3AWVb7VIkByHn00Qvafyq5f8DKjMK+1XIsvpFzZjovGitHJmFC226Ex0lBFQeRlaL0lHq4aC2IKImlooYSMnsRairXmYNkbazghZu7a/mcbhZ4hm+6ZcP9vLOX/AOlM5mftGWXk2FSTo+RUWfrU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6B144BD742; Sun, 11 Jan 2026 17:11:56 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf16.hostedemail.com (Postfix) with ESMTPA id E9C3F20022; Sun, 11 Jan 2026 17:11:52 +0000 (UTC) Date: Sun, 11 Jan 2026 12:11:51 -0500 From: Steven Rostedt To: "Theodore Tso" Cc: "Paul E. McKenney" , "Dr. David Alan Gilbert" , Julia Lawall , Sasha Levin , Gabriele Paoloni , Kate Stewart , Chuck Wolber , Dmitry Vyukov , Mark Rutland , Thomas Gleixner , Lorenzo Stoakes , Shuah Khan , Chris Mason , linux-kernel@vger.kernel.org Subject: Re: Follow-up on Linux-kernel code accessibility Message-ID: <20260111121151.39801d8d@fedora> In-Reply-To: <20260111033040.GA52543@macsyma.local> References: <435c7085-34e-16e9-5711-e53aa54cf4fc@inria.fr> <20251229104005.18b25def@gandalf.local.home> <7f10c583-4d95-432e-a536-898c79b1766d@paulmck-laptop> <20251229153517.0001e755@gandalf.local.home> <81eda579-1909-4a10-ad81-6f5551bc7db6@paulmck-laptop> <20260109095858.3401c4d9@gandalf.local.home> <20260111033040.GA52543@macsyma.local> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout07 X-Rspamd-Queue-Id: E9C3F20022 X-Stat-Signature: jebe6a71namacrqcnm66xqsqjixh5wpe X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/bKRQrLRkuIze/kcv68N2MDK/EnwOVTuw= X-HE-Tag: 1768151512-521778 X-HE-Meta: U2FsdGVkX1/xMZXupdMrrm9b9wlfSno2ILCJiWxEf4PXlQ7I82UpB3U7O9s958IfzNp6v0rSfv1Gi1GFlDzT0pbmJjQBKWqvkMKr2vD9YwUffotCtHR5Z1KpGVkXngqloLIJyTC35GiXvjf+n67R9pxJnU71oqGUYbQo72+mboECLiSwxX2dg215pib0EAR+1jJUzqmjuH467JlUXoW+F2NHjbD3uILWQFiufQLA3Ym7pFHi6jR40Z6C5Xg8A6jp5c6iFrmZXOYUYf3akAhJbYNyS4NP91UxNNGwqub040r0uq8hWqmHIwt+WUPAyMA5KFd4Rp8xyfY8ADjeWfRw24kJzdUp+qVB On Sat, 10 Jan 2026 19:30:40 -0800 "Theodore Tso" 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