Using Claude Code to modernize a 25-year-old kernel driver

Post by zipzapzip » Mon, Sep 08, 2025, 6:10 AM UTC

kccqzy wrote: post #30

bicx wrote: post #11

Earlier quoted context omitted.

This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments. One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially hav…

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

Post by theshrike79 » Mon, Sep 08, 2025, 6:14 AM UTC

rmoriz wrote: post #102

nine_k wrote: post #31

Earlier quoted context omitted.

Yes. The author essentially asked Claude to port a driver from Linux 2.4 to Linux 6.8. Very certainly there must be sufficient amounts of training material, and web-searchable material, that describes such tasks. The author provided his own expertise where Claude could not find a good analogue in the training corpus, that is, the few actually non-trivial bits of porting. "Use these tools as a massive force multiplier…

You can still ask, generate a list of things to learn etc. basically generate a streamlined course based on all tutorials, readmes and source code available when the model was trained. You can call your tutor 24/7 as long as you got tokens.

Post by eviks » Mon, Sep 08, 2025, 6:18 AM UTC

0xbadcafebee wrote: post #5

I had a suspicion AI would lower the barrier to entry for kernel hacking. Glad to see it's true. We could soon see much wider support for embedded/ARM hardware. Perhaps even completely new stripped-down OSes for smart devices.

Post by badsectoracula » Mon, Sep 08, 2025, 6:19 AM UTC

AdieuToLogic wrote: post #52

Something not yet mentioned by other commenters is the "giant caveat": 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 co…

Post by fock » Mon, Sep 08, 2025, 6:36 AM UTC

fock wrote: post #116

geor9e wrote: post #20

Earlier quoted context omitted.

"The intention is to compile this driver as an out-of-tree kernel module, without needing to copy it into the kernel source tree. That's why there's just a simple Makefile, and no other affordances for kernel inclusion. I can't really imagine any further need to build this driver into the kernel itself. The last version of the driver that was included in the kernel, right up until it was removed, was version 3.04. BU…

and there have been continous ports since then: https://github.com/Godzil/ftape/tree/master - note the caveats which apparently all disappeared here...