Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dmitrybrant.com

Post reply on HN
Print view View original

231–240 of 343 posts

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

#231

Post by TuxSH »

bgwalter wrote: post #212
rmoriz wrote: post #56

I was banned from an OpenSource project [1] recently because I suggested a bug fix. Their „code of conduct“ not only prevents PRs but also comments on issues with information that was retrieved by any AI tool or resource. Thinking about asking Claude to reimplement it from scratch in Rust… [1] https://codeberg.org/superseriousbusiness/gotosocial/src/bra...

There is no "from scratch" for "AI". Claude will read the original, launder it, strip the license and pass it off as its own work.

Indeed, LLMs cannot do truly novel thinking, and the laundering analogy is spot-on.

However they're able to do more than just regurgitating code, I can have them explain to me the underlying (mathematical or whatever) concept behind the code and write new code from scratch myself, with that knowledge.

Can/should this new code be considered as derivative work, if the underlying principles were already documented in literature?

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

#232

Post by cmpxchg8b »

kelnos wrote: post #177
rvz wrote: post #16

No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time. That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated. No thanks and no deal.

> No tests whatsoever. Test coverage between subsystems in the Linux kernel varies widely. I don't think a lack of tests would prevent inclusion. > No thanks and no deal. I mean, now we have a driver for this old hardware that runs on a modern kernel, which we didn't before. I imagine you don't even have that hardware, so why do you care if someone else gets some use out of it? The negativity here in many of these co…

Yes, the negativity is infuriating. This is the mindset that is going to get left behind. I'm no LLM maximalist but they clearly have their uses in the right context and the right hands.

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

#233

Post by matwood »

skydhash wrote: post #223
johnisgood wrote: post #207

Earlier quoted context omitted.

I think you can do this already. If you do not know the underlying concepts, or have no idea about how you have to architecture your project and so forth, then you will have problems with LLMs. So I think many if not most people who have problems with LLMs, it is most likely due to their lack of knowledge and/or their expectation that you can just simply write two sentences and it will figure out what you want and ho…

The thing is, is it slower to code with LLMs if you already have the knowledge? I think it is so. Coding is formal. There’s usually one correct way to tell the computer to do something (all the alternatives are equivalent through abstraction or transposition). The other ways are what we called bugs and there’s an infinty of them. The programming language eliminates some (incorrect syntax) while the type system get ri…

> The thing is, is it slower to code with LLMs if you already have the knowledge?

Maybe if all you do is code, but that’s not how most people work. Being able write I need these things done in this way and then attend a meeting or start researching the next thing is valuable. And because of my other obligations there’s no way I could do more without Claude.

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

#234

Post by skydhash »

kelnos wrote: post #174
AdieuToLogic wrote: post #66

Earlier quoted context omitted.

> Gatekeeping is toxic. Learning what must be done to implement a device driver in order for it to operate properly is not "gatekeeping." It is a prerequisite. > I love agents explaining me projects I don‘t know. Awesome. This is one way to learn about implementations and I applaud you for benefiting from same. > Recently I cloned sources of Firefox and asked qwen-code (tool not significant) about the AI features of…

> Learning what must be done to implement a device driver in order for it to operate properly is not "gatekeeping." It is a prerequisite. Apparently it's not, though. The author here had some baseline knowledge of how Linux kernel modules work, but the impression I got is that they would not have been able to do this on their own without a lot of learning. > the fact is that a defective device driver can lock-up the…

Anyone can write kernel module.

On their computers.

Not mine.

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

#235

Post by jillesvangurp »

mexicocitinluez wrote: post #210
jillesvangurp wrote: post #191

I think this is illustrative of the kind of productive things you can do with an LLM if you know what you are doing. Is it perfect, no. Can they do useful things if you prompt correctly, absolutely. It helps knowing what you are doing and having enough skill to make good judgment calls yourself. There are currently multiple posts per day on HN that escalate into debates on LLMs being useful or not. I think this is a…

The more you use the tools, the more you're able to recognize the situations in which they're useful. These studies keep popping up where they randomly decide whether someone will use AI to assist in a feature or not and it's hard for me to explain just how stupid that is. And how it's a fundamental misunderstanding of when and how you'd want to use these tools. It's like being a person who hangs up drywall with scre…

> I don't use it to create entire features.

I actually do this now. That's one of those things that went from impossible to doable under some circumstances. Still a bit of a coin flip but it can work well in some code bases. I still have a mental block even asking for these things under the assumption it would not work anyway. But I've been pleasantly surprised a few times where this actually works.

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

#236

Post by wg0 »

I have used Gemeni and OpenAI models too but at this point - Sonnet is next level undisputed King.

I was able to port a legacy thermal printer user mode driver from legacy convoluted JS to pure modern Typescript in two to three days at the end of which printer did work.

Same caveats apply - I have decent understanding of both languages specifically various legacy JavaScript patterns for modularity to emulate other language features that don't exist in JavaScript such as classes etc.

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

#237

Post by piskov »

wg0 wrote: post #236

I have used Gemeni and OpenAI models too but at this point - Sonnet is next level undisputed King. I was able to port a legacy thermal printer user mode driver from legacy convoluted JS to pure modern Typescript in two to three days at the end of which printer did work. Same caveats apply - I have decent understanding of both languages specifically various legacy JavaScript patterns for modularity to emulate other la…

Check swe-bench results but for C#.

It’s literally pathetic how these things just memorize, not achieve any actual problem-solving

https://arxiv.org/html/2506.12286v3

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

#238

Post by wizzwizz4 »

TuxSH wrote: post #231
bgwalter wrote: post #212

Earlier quoted context omitted.

There is no "from scratch" for "AI". Claude will read the original, launder it, strip the license and pass it off as its own work.

Indeed, LLMs cannot do truly novel thinking, and the laundering analogy is spot-on. However they're able to do more than just regurgitating code, I can have them explain to me the underlying (mathematical or whatever) concept behind the code and write new code from scratch myself, with that knowledge. Can/should this new code be considered as derivative work, if the underlying principles were already documented in li…

They can regurgitate explanations as well as code. I'd strongly recommend doing actual research: you'll find better (less-distorted, better laid out, more complete) explanations.

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

#239

Post by codedokode »

jlei523 wrote: post #157
codedokode wrote: post #154

Earlier quoted context omitted.

Also I wanted to add that LLMs (at least free ones) are pretty dumb sometimes and do not notice obvious thing. For example, when writing tests they generate lot of duplicated code and do not move it into a helper function, or do not combine tests using parametrization. I have to do it manually every time. Maybe it is because they generate the code in one pass and cannot return back and fix the issues. LLM makers, you…

Also I wanted to add that LLMs (at least free ones) are pretty dumb sometimes and do not notice obvious thing. For example, when writing tests they generate lot of duplicated code and do not move it into a helper function, or do not combine tests using parametrization. I have to do it manually every time. Do you prompt it to reduce duplicated code?

I can prompt anything but I would prefer it not to make obvious mistakes from the start.

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

#240

Post by codedokode »

scotty79 wrote: post #182
codedokode wrote: post #154

Earlier quoted context omitted.

Also I wanted to add that LLMs (at least free ones) are pretty dumb sometimes and do not notice obvious thing. For example, when writing tests they generate lot of duplicated code and do not move it into a helper function, or do not combine tests using parametrization. I have to do it manually every time. Maybe it is because they generate the code in one pass and cannot return back and fix the issues. LLM makers, you…

> I have to do it manually every time. You can tell it to move it and they'll move it and use this shared code from now on.

Sometimes it seems like explaining what I want could take more time than actually editing the code.

For example, imagine if you test a vector-like collection. In every test case dumb LLM creates vector manually and makes inserts/deletes. It could be replaced by adding a helper function that accepts a sequence of operations and returns the processed vector. Furthermore, once you have that function, you can merge multiple tests with parametrization, by having a test function accept a sequence of operation and expected result:

    parametrize('actions, result', (
        # Test that remove removes items from vector
        ([Ins(1, 2, 3, 4), Remove(4)], [1, 2, 3]),
        ...
    )
But it takes time to write this explanation, and dumb LLM might not merge all tests from the first time.
Post reply on HN