All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <roman.gushchin@linux.dev>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
Date: Fri, 17 Jul 2026 14:14:49 -0700	[thread overview]
Message-ID: <78346752-E2AC-4ACB-929D-70A45794474C@linux.dev> (raw)
In-Reply-To: <9e10dc4f-5d5c-4c20-831c-9137e719b337@kernel.org>

> On Jul 17, 2026, at 2:05 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> On 15/07/2026 18:55, Roman Gushchin wrote:
>> * Prompt development and testing.
>> Currently, prompts are maintained in two GitHub repositories and are
>> changed manually or with the help of AI coding agents. However, there is
>> no established practice for testing them, especially across various LLM
>> models. At the last LSFMMBPF conference, there was a discussion about
>> moving them into the kernel tree. I see some pros and cons to this
>> approach, but the ownership and testing models are not entirely clear.
> 
> Prompts in a meaning how to parse kernel, work with it or produce
> reports: yeah, sure.
> 
> Prompts teaching kernel code: I don't think so. I find it really
> incorrect approach to create a dedicated and duplicated basic knowledge
> for LLMs, instead of focusing on knowledge for developers. I understand
> that LLM has to be taught basics of C [1], but we should not duplicate
> kernel coding style or kernel rules into LLM-only instructions. Instead:

I agree.
I also experiment with Sashiko auto-creating prompts based on human
feedback in emails and initial results look promising. So maybe we don’t
even need to write too much manually for LLMs.

Thanks!

> 
> 1. Fix docs or kerneldoc to have these properly documented,
> 2. Instruct LLM to read these documents.
> 
> We do have tribal knowledge and it should be our kernel docs for the
> developers, first of all. If the knowledge is so important for LLM that
> it must be duplicated in prompts (just read some of the subsystem
> specifics at [2]), then maybe better add it to some guide "writing HID
> driver" or "common mistakes in Bluetooth", so developer writing such
> driver that will find it. And LLM too.
> 
> I keep growing such codified and condensed (keep as short as possible)
> rules for subsystem I am part of [3] and LLM should read that one. LLM
> does not need dedicated doc, different than developers need. Well,
> except teaching C. [1] :)

This is awesome actually!

      reply	other threads:[~2026-07-17 21:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 16:55 [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process Roman Gushchin
2026-07-15 17:51 ` Miguel Ojeda
2026-07-15 21:37   ` Roman Gushchin
2026-07-17  6:43     ` Ben Copeland
2026-07-16 15:32   ` Sasha Levin
2026-07-15 17:56 ` Mauro Carvalho Chehab
2026-07-15 18:57 ` Jason Gunthorpe
2026-07-15 21:21   ` Roman Gushchin
2026-07-16 22:26     ` Mauro Carvalho Chehab
2026-07-17 23:17     ` Linus Torvalds
2026-07-18  0:01       ` Mark Brown
2026-07-18  1:09       ` Laurent Pinchart
2026-07-18  1:17         ` Linus Torvalds
2026-07-15 19:45 ` Dmitry Torokhov
2026-07-16  0:03 ` Steven Rostedt
2026-07-16  0:30 ` SJ Park
2026-07-17 21:05 ` Krzysztof Kozlowski
2026-07-17 21:14   ` Roman Gushchin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=78346752-E2AC-4ACB-929D-70A45794474C@linux.dev \
    --to=roman.gushchin@linux.dev \
    --cc=krzk@kernel.org \
    --cc=ksummit@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.