On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote: > On 1/7/26 10:12, Lorenzo Stoakes wrote: > ... > > I know Linus had the cute interpretation of it 'just being another tool' > > but never before have people been able to do this. > > I respect your position here. But I'm not sure how to reconcile: > > LLMs are just another tool > and > LLMs are not just another tool > > :)
Well I'm not asking you to reconcile that, I'm providing my point of view which disagrees with the first position and makes a case for the second. Isn't review about feedback both positive and negative? Obviously if this was intended to simply inform the community of the committee's decision then apologies for misinterpreting it. I would simply argue that LLMs are not another tool on the basis of the drastic negative impact its had in very many areas, for which you need only take a cursory glance at the world to observe. Thinking LLMs are 'just another tool' is to say effectively that the kernel is immune from this. Which seems to me a silly position. > > Let's look at it another way: What we all *want* for the kernel is > simplicity. Simple rules, simple documentation, simple code. The > simplest way to deal with the LLM onslaught is to pray that our existing > rules will suffice. I'm not sure we really have rules quite as clearly as you say, as subsystems differ greatly in what they do. For one mm merges patches unless averse review is received. Which means a sudden influx of LLM series is likely to lead to real problems. Not all subsystems are alike like this. One rule that seems consistent is that arbitrary dismissal of series is seriously frowned upon. The document claims otherwise. > > For now, I think the existing rules are holding. We have the luxury of We're noticing a lot more LLM slop than we used to. It is becoming more and more of an issue. Secondly, as I said in my MS thread and maybe even in a previous version of this one (can't remember) - I fear that once it becomes public that we are open to LLM patches, the floodgates will open. The kernel has a thorny reputation of people pushing back, which probably plays some role in holding that off. And it's not like I'm asking for much, I'm not asking you to rewrite the document, or take an entirely different approach, I'm just saying that we should highlight that : 1. LLMs _allow you to send patches end-to-end without expertise_. 2. As a result, even though the community (rightly) strongly disapproves of blanket dismissals of series, if we suspect AI slop [I think it's useful to actually use that term], maintains can reject it out of hand. Point 2 is absolutely a new thing in my view. > treating LLMs like any other tool. That could change any day because > some new tool comes along that's better at spamming patches at us. I > think that's the point you're trying to make is that the dam might break > any day and we should be prepared for it. > > Is that what it boils down to? I feel I've answered that above. > > >> +As with all contributions, individual maintainers have discretion to > >> +choose how they handle the contribution. For example, they might: > >> + > >> + - Treat it just like any other contribution. > >> + - Reject it outright. > > > > This is really not correct, it's simply not acceptable in the community to > > reject series outright without justification. Yes perhaps people do that, > > but it's really not something that's accepted. > > I'm not quite sure how this gives maintainers a new ability to reject > things without justification, or encourages them to reject > tool-generated code in a new way. > > Let's say something generated by "checkpatch.pl --fix" that's trying to > patch arch/x86/foo.c lands in my inbox. I personally think it's OK for > me as a maintainer to say: "No thanks, checkpatch has burned me too many > times in foo.c and I don't trust its output there." To me, that's > rejecting it outright. > > Could you explain a bit how this might encourage bad maintainer behavior? I really don't understand your question or why you're formulating this to be about bad maintainer behaviour? It's generally frowned upon in the kernel to outright reject series without technical justification. I really don't see how you can say that is not the case? LLM generated series won't be a trivial checkpatch.pl --fix change, you've given a trivially identifiable case that you could absolutely justify. Again, I'm not really asking for much here. As a maintainer I am (very) concerned about the asymmetry between what can be submitted vs. review resource. And to me being able to reference this document and to say 'sorry this appears to be AI slop so we can't accept it' would be really useful. Referencing a document that tries very hard to say 'NOP' isn't quite so useful. Thanks, Lorenzo
