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 430CE28640F for ; Fri, 19 Dec 2025 17:12:43 +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=1766164366; cv=none; b=iqdZOQEH+YIYxhZVswVI8gsju2zh5KkvLe/jRRFBQFiswgcpi0raCqaQdt+5ad2l4cl92y64F3bl1T/LT2Dz/v739X3dqP7kmi0vft75EgDihtwbmteiEueRh8KeOoklKSVRcQxuYML0mi56AW+6ps7j+eNCG5NJkRbbGG7ZXB4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766164366; c=relaxed/simple; bh=45J75MUKERH5VwH68xJKIOsEy9exxVzJTQy3IMthyvE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YiSzUVBAUZ3ff77YWvbAI493fK+bpZlEblbLP8ffMIwEs93ofuNdxyAEJ0aBOtW/y9Y6lvs26lBNjwLpAAS2s4ErFebM8OZ9QHS+S2KG9rvh87DEgMl3zbE7+pdEgYCn0I/cZgOsNF4Fqw3ObRZDKKRO1MJTwX5P5HlqcPplZ2Q= 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=LGBvvZGR; 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="LGBvvZGR" Received: from macsyma.thunk.org (pool-173-48-82-200.bstnma.fios.verizon.net [173.48.82.200]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 5BJHAkrL019032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Dec 2025 12:10:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1766164249; bh=2fqGr9H2HJbB70CoVf7x2FBp07cOHIHzlt8zZHGqV3Y=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=LGBvvZGRxVSife5U9IhhSoDkxcC11kHFFT1wW0QBXtSX6HZdyeeuWILIDRqvrmuwc 6E78izCwG3srMpGPvYeZVToYHL+6d3A0m+lGzcb/qJZmDUyOYnGQZTKrRyTtxFpRWJ HvGSTqaUsoJniyAjELb4X/pneiwnmyDHOfGCb/Mly8l6GS69bVlsL+7H6ro/TkmyM3 gg8smGV/fMGjeF3ZctOnnHj7DbYoM8knsm+mHvbZZ4HaK9NM1+tPn7MAJAAxfhIDwV udqGnglNEtfjgYfp5fieWEIL0z7XiTNdxSMViNyoEuPPrO18y2C33Fbg+r5Y7q/Ge8 4By1iinmbiB9A== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 72D4B50CA6CE; Fri, 19 Dec 2025 12:09:45 -0500 (EST) Date: Fri, 19 Dec 2025 12:09:45 -0500 From: "Theodore Tso" To: Julia Lawall Cc: "Paul E. McKenney" , Gabriele Paoloni , Steven Rostedt , Kate Stewart , Chuck Wolber , Dmitry Vyukov , Mark Rutland , Thomas Gleixner , Lorenzo Stoakes , Shuah Khan , Sasha Levin , Chris Mason , linux-kernel@vger.kernel.org Subject: Re: Follow-up on Linux-kernel code accessibility Message-ID: <20251219170945.GA32430@macsyma.lan> References: <90d56d30-232d-4930-ad9f-5aebade7cdf2@paulmck-laptop> <636d1798-3b37-293a-51b2-55d2ecc6d2d@inria.fr> 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: <636d1798-3b37-293a-51b2-55d2ecc6d2d@inria.fr> On Fri, Dec 19, 2025 at 07:51:47AM +0100, Julia Lawall wrote: > > Maybe we're not looking for an instant understanding methodology. Rather > a machine checkable way to document the invariants that exist in the head > of the developer, and for some bounded amount of time in the head of the > person who has tried to reconstruct them. One of the things that I found really interesting with Chris Mason's kernel review prompts is that it documents some of these invariants which are not otherwise covered in the kernel documentation. And while Chris originally created those prompts for Anthropic's Claude LLM, we've successfully used them with Gemini 2.5 and 3. I wonder if we should consider folding them into the kernel sources, so they can be updated alongside the kernel. It might also mean that as the invariants change, the documentation / prompts in an LTS kernel and for the latest upstream kernel can be up to sync with the relevant kernel versions. > Maybe the low-level ones could be made > 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. Cheers, - Ted