Note, LLMs are very good at finding suspect “security issues” in kernel code these days. But even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful. So, if you think your LLM-found/fixed issue in a drivers/staging/ file is really valid, it’s fine to submit it BUT you must have first tested it on the actual hardware for the driver, and described how you have done so, in order for us to be willing to take the change.
Record time speedrun from “I’m putting my foot down in favor of AI” to “at least 1/3 of patches are flat out wrong or harmful”, eh?
Complete misunderstanding of what he actually said, you only read the headlines.
Yeah, all other commenters here just didn’t read the article it seems.
First off, drivers/staging/ exists PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development. It contains loads of “low hanging fruit” with regards to code cleanups and api changes, perfect for new developers to learn the process in a safe and friendly way, with no pressure as no one should be relying on the code in these directories
<…>
In other words, drivers/staging/ here is a “gym” that is here to learn and grow your skills with. A LLM is turning into a reasonable tool to do “heavy lifting” for some things but that should only be done by those that have already properly trained their skills to know what type of lifting can be done, and in what way. See this great essay by Bruce Schneier for where he explains this in much better detail."
I think it was more a declaration of neutrality
Exactly this. Linus doesn’t give a shit if the garbage came from meat or a clanker, he treats all garbage equally.
If it’s obviously AI, you may get a silent rejection instead of a public beating.
If it’s not garbage, you may get a change request email!
Just like in a lot of other topics, neutrality doesn’t exist here. If you’re not actively opposing evil, you’re supporting it. As a narrow example, be “neutral” to slop, drown in it immediately.
It’s easy to not have a problem with AI merge requests when you have a whole team of people filtering out the garbage before it gets to you.
It was “I’m putting my foot down in favor of AI” for finding security flaws and triaging issues, not writing code. Shit’s useful for things that can be easily verified, like security flaws, less so (OK, crap) for writing maintainable code in a massive codebase with highly complex interactions.
AI is a tool, its just that most people seem to not understand that you don’t want to use a screw driver as a hammer
And before anyone goes crazy about me defending AI, I’m not. At least not the AI we see today with the world destroying data centers and so on. Every tool has its uses, so does AI, its just that the real use cases are highly limited
Nice, I can get behind that policy. LLMs can be useful but only if you assume the output is wrong until proven correct. Using it to find potential threads to pull at makes sense to me but not blindly trusting everything it points out
Actually proving that C code is correct is not easy.
Having a human developer manually write code that is less harmful/wrong, and doesn’t require proof, is probably easier.
Except a good programmer will have proof, in the form of at minimum manual tests that exercise the exact issue. A good programmer will have automated tests that clearly assert the behavior in question.
It genuinely boggles my mind when people whine about having to prove what the AI said… THEY SHOULD’VE BEEN DOING THAT THE WHOLE FUCKING TIME in their entire career!
No one proves their code is correct except in extremely niche cases. No idea what you’re talking about.
Maybe think of test driven development not like proving the code is correct, but failing to prove it’s broken.
We’re talking about different kind of proofs.
Proving a program is correct requires a formal specification and a formal verification with mathematics and/or formal methods. ie proving the behavior and result perfectly match specification for all possible inputs.
A test only proves that a program 1) returns the expected output for a specific input, or limited set of inputs, and 2) appears to behave correctly, ie there may be undefined behaviour but they don’t cause an immediate crash.
lol no. Absolutely no. In any way. Ever. A bug either works or it doesn’t. The fact you think I’m talking about something else means you are already cooked, utterly and completely. Sad.
So you prove you fixed the bug. How do you test to prove you didn’t introduce another?
AI is a tool. And with every tool, there is a right way to use it, and a wrong way to use it.
