These are standards of a normal university operating systems course (assuming a university worth its salt anyway). Ridiculous to present it as some kind of feat that was "impossible" or even that rare.
this https://codeberg.org/lrvick/nit/src/branch/main/src/system/r...
is textbook definition of boilerplate. you need to be patient to cross-reference syscall tables but certainly not smart.
Again, students learning about operating systems do similar things as a normal part of their education process.
I'm not saying LLMs wouldn't help with this (in fact, this is the type of thing that becomes pretty much a no-op with them) but the notion that this is "impossible by any realistic standards" is risible, and if you have actually contributed to the kernel like you say, you should know better.
https://codeberg.org/lrvick/nit/src/branch/main/tests/kernel...
That is the point. Getting to results that satisfy security and functionality requirements in much less time.
Also, I was able to generate a bare minimal and hardened kernel config by using the LLM to write a tool to trace all kernel calls. Something that I would have normally been forced to punt on that LLMs made easy to justify.
LLMs are just as Linus Torvalds likes to say "Auto complete on steroids".
How often does "this table of constants was transcribed incorrectly" even come up as a bug class? Is it worth writing a buggy C parser for a failure mode that doesn't happen? Do you expect that Linux is going to change their constant definitions out from under you?
> Do you expect that Linux is going to change their constant definitions out from under you
Unlikely but I have been surprised before. Hardcoding to pretty much any modern kernel source version forever for this narrow use case is probably fine.
The goal is about helping me and a reviewer quickly form confidence none of the magic numbers are mistaken or malicious in an automated way against the source of truth.