From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: ksummit@lists.linux.dev
Subject: [MAINTAINERS SUMMIT] The role of AI and LLMs in the kernel process
Date: Tue, 5 Aug 2025 17:03:18 +0100 [thread overview]
Message-ID: <e3188fe2-4b6c-4cb2-b5ae-d36c27de6832@lucifer.local> (raw)
Unavoidably, LLMs are the hot topic in tech right now, and are here to
stay.
This poses unique problems:
* Never before have people been able to generate as much content that may,
on a surface reading, seem valid whilst in reality being quite the
opposite.
* Equally, LLM's can introduce very subtle mistakes that humans find
difficult to pick up upon - humans implicitly assume that the classes of
errors they will encounter are the kinds other humans would make - AI
defeats that instinct.
* The kernel is uniquely sensitive to erroneous (especially subtly
erroneous) code - even small errors can be highly consequential. We use a
programming language that can almost be defined by its lack of any kind
of safety, and in some subsystems patches are simply taken if no obvious
problems exist, making us rather vulnerable to this.
* On the other hand, there are use cases which are useful - test data/code
generation, summarisation, smart auto-complete - so it'd perhaps be
foolish to entirely dismiss AI.
A very important non-technical point we must consider is that, the second
we even appear to be open to AI submission of _any_ kind, the press will
inevitably report on it gleefully, likely with oversimplified headlines
like 'Linux accepts AI patches'.
The moment that happens, we are likely to see a significant uptick in AI
submissions whether we like it or not.
I propose that we establish the broad rules as they pertain to the kernel,
and would like to bring the discussion to the Maintainer's Summit so we can
determine what those should be.
It's important to get a sense of how maintainers feel about this - whether
what is proposed is opt-in or opt-out - and how we actually implement this.
There has been discussion on-list about this (see [0]), with many
suggestions made including a 'traffic light' system per-subsystem, however
many open questions remain - the devil is in the details.
[0]:https://lore.kernel.org/all/20250727195802.2222764-1-sashal@kernel.org/
next reply other threads:[~2025-08-05 16:03 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 16:03 Lorenzo Stoakes [this message]
2025-08-05 16:43 ` James Bottomley
2025-08-05 17:11 ` Mark Brown
2025-08-05 17:23 ` James Bottomley
2025-08-05 17:43 ` Sasha Levin
2025-08-05 17:58 ` Lorenzo Stoakes
2025-08-05 18:16 ` Mark Brown
2025-08-05 18:01 ` Lorenzo Stoakes
2025-08-05 18:46 ` Mark Brown
2025-08-05 19:18 ` Lorenzo Stoakes
2025-08-05 17:17 ` Stephen Hemminger
2025-08-05 17:55 ` Lorenzo Stoakes
2025-08-05 18:23 ` Lorenzo Stoakes
2025-08-12 13:44 ` Steven Rostedt
2025-08-05 18:34 ` James Bottomley
2025-08-05 18:55 ` Lorenzo Stoakes
2025-08-12 13:50 ` Steven Rostedt
2025-08-05 18:39 ` Sasha Levin
2025-08-05 19:15 ` Lorenzo Stoakes
2025-08-05 20:02 ` James Bottomley
2025-08-05 20:48 ` Al Viro
2025-08-06 19:26 ` Lorenzo Stoakes
2025-08-07 12:25 ` Mark Brown
2025-08-07 13:00 ` Lorenzo Stoakes
2025-08-11 21:26 ` Luis Chamberlain
2025-08-12 14:19 ` Steven Rostedt
2025-08-06 4:04 ` Alexey Dobriyan
2025-08-06 20:36 ` Sasha Levin
2025-08-05 21:58 ` Jiri Kosina
2025-08-06 6:58 ` Hannes Reinecke
2025-08-06 19:36 ` Lorenzo Stoakes
2025-08-06 19:35 ` Lorenzo Stoakes
2025-08-05 18:10 ` H. Peter Anvin
2025-08-05 18:19 ` Lorenzo Stoakes
2025-08-06 5:49 ` Julia Lawall
2025-08-06 9:25 ` Dan Carpenter
2025-08-06 9:39 ` Julia Lawall
2025-08-06 19:30 ` Lorenzo Stoakes
2025-08-12 14:37 ` Steven Rostedt
2025-08-12 15:02 ` Sasha Levin
2025-08-12 15:24 ` Paul E. McKenney
2025-08-12 15:25 ` Sasha Levin
2025-08-12 15:28 ` Paul E. McKenney
2025-12-08 1:12 ` Sasha Levin
2025-12-08 1:25 ` H. Peter Anvin
2025-12-08 1:59 ` Jonathan Corbet
2025-12-08 3:15 ` Steven Rostedt
2025-12-08 3:42 ` James Bottomley
2025-12-08 8:41 ` Mauro Carvalho Chehab
2025-12-08 9:16 ` James Bottomley
2025-12-08 10:22 ` Mauro Carvalho Chehab
2025-12-08 4:15 ` Laurent Pinchart
2025-12-08 4:31 ` Jonathan Corbet
2025-12-08 4:36 ` Laurent Pinchart
2025-12-08 7:00 ` Jiri Kosina
2025-12-08 7:38 ` James Bottomley
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=e3188fe2-4b6c-4cb2-b5ae-d36c27de6832@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox