Claude Code LLM for porting ancient Linux drivers?

12 Sep, 2025

LLMs are all the rage now, Markov chains are just about one (1) glued on Agent short of becoming self-aware.

Let me quote Arnold for a second: "The Skynet Funding Bill is passed. The system goes online August 4th, 1997. Human decisions are removed from strategic defense. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug."

This is just like in the movies! 500 Billion Dollars Stargate Project by OpenAI! Announced on January 21, 2025 will inevitably lead to AGI and global, thermonuclear war.

Every day there is a new LLM, company, blog that evangelizes "statistics" in a borderline hysterical tone by people selling shovels in a goldrush. 50.000 words long blogposts are written about the newest canned benchmarks but where is the actual code?

Well, now I've seen a blogpost with actual code for a change - even low-level Linux kernel C code! It's a popular post on Hacker News, 300 comments, 900 points, Top 3 News of the Day, with a lot of comments about feelings about LLMs but not a single one about the actual code.

https://news.ycombinator.com/item?id=45163362

https://dmitrybrant.com/2025/09/07/using-claude-code-to-modernize-a-25-year-old-kernel-driver

Porting a floppy driver from 2000 to 2025 - how hard could it be... :P

So I took the time and looked at the code. Downloaded the two branches and compared them in Beyond Compare and at first glance it looks overwhelming. So many touched files.

Checking out the biggest file, something becomes quickly obvious: the vast majority of changes are the removal of preprocessor directives checking for older Kernel version and the code belonging to them! I highlighted the only change that required thinking. The current variable became a function and the question is - did Claude actually create this change?

This pattern repeats itself across the whole repo. I have not gone over every change but the following categories stood out:

1 removal of #if checks for kernel version < 2.x.y and code for older versions

2 removal of #includes config.h asm/system.h

3 removal of #defines #includes used for tracing

4 modifying macros, eg for logging KERN_INFO or FUNCTION

5 variable/function rename, eg current to get_current_state() or idle to waiting

6 function definition moves, like fdc_probe() to fdc-io.c

7 wrapper for eg zft_ioctl() and parport

Below is the HTML diff report generated by Beyond Compare. It only contains the line diffs and no context around them but still the only code worth looking at is in zftape-init.c for loading and unloading the module. The author says that he already has experience with kernel modules and you can see that he has a lot of experience with C due to his other software. So I don't really believe the quote below:

"Use these tools as a massive force multiplier of your own skills. I’m sure that if I really wanted to, I could have done this modernization effort on my own. But that would have required me to learn kernel development as it was done 25 years ago. This would have probably taken me several weeks of nonstop poring over documentation that would be completely useless knowledge today. Instead of all that, I spent a couple of days chatting with an agent and having it explain to me all the things it did."

To be honest, I don't buy it. Several weeks of reading docs to remove preprocessor directives? Kernel dev from 25 years ago? But the ported code is identical. To put in "module_put(THIS_MODULE); /* unlock module in memory */"? Where is the multiplier? What did Claude actually do? Parsed and removed the #ifdefs?

Below is the author actually saying what sound realistic.

"As a giant caveat, I should note that I have a small bit of prior experience working with kernel modules, and a good amount of experience with C in general, so I don’t want to overstate Claude’s success in this scenario. As in, it wasn’t literally three prompts to get Claude to poop out a working kernel module, but rather several back-and-forth conversations and, yes, several manual fixups of the code. It would absolutely not be possible to perform this modernization without a baseline knowledge of the internals of a kernel module."

But if you went through a tutorial on creating, loading, unloading your first kernel module and know C to a good degree, how is Claude helping here? Is it not just a transformative formatter? What were the manual fixes?

Anyway, the point here is that Hacker News comments are amusing. Don't swallow the hype wholesale lest you start selling shovels.