From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 BA5C81E515 for ; Sun, 11 Jan 2026 03:32:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768102333; cv=none; b=Hc/kaA5Jg2qdtD6zOtWwYrMMDYDfhRR5KGrs5l6tWugW5OVqxP3S4Hvm+njAjIQn9lykFEcYNBr/3OYF93OdvhT3qbtSsc4VeaeiLaFQNW3TiEpakiCbpOXtbW/wVbz5HVlWXLAld2g4GIdYo7LHmM6afmAGa3bAf/sfIh0SqYM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768102333; c=relaxed/simple; bh=sxRogEP6NvZM2mOxTn1CUmsymH1HcRa285YjIojODu4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EkvM5SS7P0kNrs5SmIU6LCImaa+UO0AtQD2XRG7AbBytslBO4Mu79X8hAC4/DTCZgLYh2JnGBROA4qCsylFa6iAAxq0i4OpEH7d9sk4KC2ZQHcLl8bOmry8TsWfo7HoEu8cijWXfDmnEREYiUmbexd1qgvGo6J1qJFFqCGrNMm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=YLb9hCCq; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="YLb9hCCq" Received: from macsyma.thunk.org ([207.200.207.67]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 60B3UfdY015245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jan 2026 22:30:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1768102247; bh=8sl5acLlavewt0LGFbkt0eub2AC8sdUxpN/XullyB3I=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=YLb9hCCq1MJljWn/xjr2+qAud4SX9RhK6NYTxIZZXlITyWHp/yqaP7xEIJqvpRSZp TLkIe5AloUTzzOV5WlBoaFCR8knk5bax5YUrO899gqoZM1hs1jQO2pfrYqC4b/6KOr o9+yEFQqa9sMWgkPQ/ymnrwx5subVfPYgfEbkGyjxDYBIZSUncMMMEMjnvw+TiW8qN nR+Zuh4JqLQkK6/b8hyjjoKBfsMg3USJU5wICfmasUd1S9np0hb+TZCUFp+NEJC3AB TfxVgRpMrKWr4kPv7opA4/bdqeQvAvjxrNtFciWpwwanidfQPrJ02iHjEeOGY5uNIU 6UKw86xdZNHPw== Received: by macsyma.thunk.org (Postfix, from userid 15806) id E6B4654356B3; Sat, 10 Jan 2026 19:30:40 -0800 (PST) Date: Sat, 10 Jan 2026 19:30:40 -0800 From: "Theodore Tso" To: Steven Rostedt 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: <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> 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-Disposition: inline In-Reply-To: <20260109095858.3401c4d9@gandalf.local.home> On Fri, Jan 09, 2026 at 09:58:58AM -0500, Steven Rostedt wrote: > > OK so this is part of the contention here. This thread turned slightly away > from the original topic and moved towards the importance of commenting > code, at least for me. But if you were still discussing this as a > requirement document of some kind, then the comment on the "3" is out of > scope. Looking at the original context of of the first message[1] in this thread, the thesis statement of Paul's message was that commenting code was *not* a viable way of enabling who want to do "random dives" into kernel code to understand it. [1] https://lore.kernel.org/r/90d56d30-232d-4930-ad9f-5aebade7cdf2@paulmck-laptop Quoting from that first message: "The Linux kernel's mm system weighs in at about 200KLoC, and Lorenzo wrote a book on its design that weighs in at about 1300 pages, or about 150 LoC/page. This suggests that the Linux-kernel scheduler, which weighs in at about 70KLoC and has similar heuristics/workload challenges as does mm, would require a 430-page textbook to provide a similar level of design detail. By this methodology, RCU would require "only" 190 pages, presumably substituting its unfamiliarity for sched's and mm's deeply heuristic and workload-dependent nature. Sadly, this data does not support the hypothesis that we can create comments that will provide understanding to people taking random dives into the Linux kernel's source code. In contrast to code that is closely associated with a specific type of mechanical device, Linux-kernel code requires the reader to possess a great deal of abstract and global conceptual/workload information." Steven, you may disagree with this conclusion, but speaking personally, everything that I've read on this thread strongly confirms it. 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 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. Cheers, - Ted