Re: [LSF/MM/BPF TOPIC] Documenting the correct pushback on AI inspired (and other) fixes in older drivers

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Feb 06, 2026 at 09:57:45AM +1100, Finn Thain wrote:
> 
> On Thu, 5 Feb 2026, James Bottomley wrote:
> 
> > To set the stage, we in SCSI have seen an uptick in patches to older
> > drivers mostly fixing missing free (data leak) and data race problems.
> > I'm not even sure they're all AI found, but we don't really need to
> > know that. 
> 
> If I may predict the next scene, by extrapolating only a little, we are 
> approaching the point where it will be feasible to request that an AI 
> simply generate a new driver, based on chip datasheets plus all of the 
> open source drivers available for training, rather than patch the bugs in 
> an existing driver.
> 
> At that point, what use is a maintainer? I think we can still add value if 

Being a magic sources of datasheets obtained through murky means,
obviously.  What /was/ grandpa doing when he came home with a bunch of
weird machinery at 3am in 1957??  :P

--D

> we are able to leverage our ability and experience in validating such code 
> i.e. prove its correctness somehow. If we can do that, then the codebase 
> we presently call Linux might continue to grow because it would remain 
> superior than some AI-generated alternative codebase.
> 
> Documentation that would raise the bar for patch submissions seems like a 
> band-aid. The basic complaint seems to be that minor fixes have become 
> cheaper and easier to produce, overwhelming reviewers. The solution has to 
> be, make code review cheaper and more effective i.e. fight fire with fire.
>