get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K. Everything below that offset is then ...
Ha! I recently went through a similar process, trying to get some hardware working for a different project that would close some 15+ year old bugs. AI helped me find it, getting sidetracked by several other small bugs in the same few files along the way.
I then wrote the actual fixes myself as a series of very small PRs. They’re all just a handful of lines each, enabling certain hardware flags, properly bounds checking loops, getting a timer initialization corrected, etc. They are all the sort of thing that once you see where they are, the fix is extremely obvious.
In the meantime, the project has adopted a very strict no AI assistance at all policy after some internal debate that almost tore the project apart.
So now I’m sitting on almost a dozen fixes for longstanding problems and have no idea if I should lie and say yes, I found these entirely by myself, or tell the truth, probably get kicked out of the project, and see how much of a shit storm they cause.
Both extremes are absolutely maddening here. I’m getting as sick of the anti-AI crowd as I am the vibe-code-tech-bros. At this point you could just put them all in a sack and start hitting them with sticks and wouldn’t care who got the worst of it.
There’s a definite middle-ground here. Linus is one of the ultimate pragmatists and it shows here. It was helpful - so he used it. It helped you so you used it. I’ve found it to be incredibly helpful so I use it.
Not all usages are equal just as all hand-written code is not equal. There are good ways to use these tools and bad ways. But the tools themselves are still just tools.
Yeah, it’s like a calculator. Don’t get reliant on it. Know why it gives an answer, be able to get to the answer yourself, but appreciate the time saving of the calculator when you can verify that it was correct much faster than getting to the answer yourself.
The art of using a digital calculator is being able to put in a problem that would take you a couple of minutes to solve, get the calculator’s answer in a couple of seconds, AND be able to spot-check the reasonable-ness of the answer in a couple of seconds more. Blind trust is ridiculously risky, cutting your speed by half to move from 99% correct to 99.99% correct is well worth the extra time and effort invested.
the anti AI slop is damaging. when politicians want AI to control nukes they are going to point to the chuds using a hammer on a screw as proof it’s all curated engagement hysteria. legitimate concerns will be treated like UFO sightings. it’s like false rape accusations. the more you cry wolf the less inclined people are to believe you when a real fear is expressed.
Honestly 15+ year old bugs are also left in the linux kernel for people to pick up, Learn from and get deeper in kernel development. They know they can easily find them with a LLM but choose not to. Policy’s are changing due to the mass influx of these “bug” fixes.
There’s academic exercises for education. The production kernel used by billions around the world is no place to intentionally leave bugs, and it doesn’t matter how they’re detected. What matters is if they are corrected without creating regressions.
Not really… “Education” and real world are vastly different. Getting accustomed to a mailing list other maintainers etc is not something you learn with your education.
And leaving bugs for hardware no one has touched in ages is not too big of a deal. And a nice gateway for new comers who actually want to learn it instead of trow a LLM at it.
Ha! I recently went through a similar process, trying to get some hardware working for a different project that would close some 15+ year old bugs. AI helped me find it, getting sidetracked by several other small bugs in the same few files along the way.
I then wrote the actual fixes myself as a series of very small PRs. They’re all just a handful of lines each, enabling certain hardware flags, properly bounds checking loops, getting a timer initialization corrected, etc. They are all the sort of thing that once you see where they are, the fix is extremely obvious.
In the meantime, the project has adopted a very strict no AI assistance at all policy after some internal debate that almost tore the project apart.
So now I’m sitting on almost a dozen fixes for longstanding problems and have no idea if I should lie and say yes, I found these entirely by myself, or tell the truth, probably get kicked out of the project, and see how much of a shit storm they cause.
Both extremes are absolutely maddening here. I’m getting as sick of the anti-AI crowd as I am the vibe-code-tech-bros. At this point you could just put them all in a sack and start hitting them with sticks and wouldn’t care who got the worst of it.
There’s a definite middle-ground here. Linus is one of the ultimate pragmatists and it shows here. It was helpful - so he used it. It helped you so you used it. I’ve found it to be incredibly helpful so I use it.
Not all usages are equal just as all hand-written code is not equal. There are good ways to use these tools and bad ways. But the tools themselves are still just tools.
Yeah, it’s like a calculator. Don’t get reliant on it. Know why it gives an answer, be able to get to the answer yourself, but appreciate the time saving of the calculator when you can verify that it was correct much faster than getting to the answer yourself.
This isn’t such a simple question.
If you think about it that way, the atomic bomb is also a kind of tool, but not everyone is allowed to use it…
If a tool starts thinking for you, it’s clearly a different kind of tool than most known tools. Different tools have different safety procedures. :)
The art of using a digital calculator is being able to put in a problem that would take you a couple of minutes to solve, get the calculator’s answer in a couple of seconds, AND be able to spot-check the reasonable-ness of the answer in a couple of seconds more. Blind trust is ridiculously risky, cutting your speed by half to move from 99% correct to 99.99% correct is well worth the extra time and effort invested.
the anti AI slop is damaging. when politicians want AI to control nukes they are going to point to the chuds using a hammer on a screw as proof it’s all curated engagement hysteria. legitimate concerns will be treated like UFO sightings. it’s like false rape accusations. the more you cry wolf the less inclined people are to believe you when a real fear is expressed.
Comment written by 💯 human
Honestly 15+ year old bugs are also left in the linux kernel for people to pick up, Learn from and get deeper in kernel development. They know they can easily find them with a LLM but choose not to. Policy’s are changing due to the mass influx of these “bug” fixes.
That’s in the Linux staging tree, where they have banned ai contribution for exactly that reason.
https://www.phoronix.com/news/Linux-Staging-Reject-LLMs
There’s academic exercises for education. The production kernel used by billions around the world is no place to intentionally leave bugs, and it doesn’t matter how they’re detected. What matters is if they are corrected without creating regressions.
Not really… “Education” and real world are vastly different. Getting accustomed to a mailing list other maintainers etc is not something you learn with your education.
And leaving bugs for hardware no one has touched in ages is not too big of a deal. And a nice gateway for new comers who actually want to learn it instead of trow a LLM at it.