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

171–180 of 343 posts

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

#171

Post by matwood »

baq wrote: post #122
ZYbCRq22HbJ2y7 wrote: post #32

Earlier quoted context omitted.

We have members on my team that definitely feel empowered to wade into new territory, but they make so much misdirected code with LLMs, even when we make everyone use Claude 4 thinking agents. It seems to me that if you have been pattern matching the majority of your coding career, then you have a LLM agent pattern match on top of that, it results in a lot of headaches for people who haven't been doing that on a team…

> they make so much misdirected code with LLMs just points to the fact that they've no idea what they're doing and would produce different, pointless code by hand, though much slower. this is the paradigm shift - you need a much bigger sieve to filter out the many more orders of magnitude of crap that inexperienced operators of LLMs create.

It'll be interesting if tools like Claude will end up being used to highlight the people who have no clue what they are doing.

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

#172

Post by matwood »

theshrike79 wrote: post #114
Brendinooo wrote: post #13

When I read an article like this it makes me think about how the demand for work to be done was nowhere close to being fully supplied by the pre-LLM status quo.

LLM assisted coding can get you from an idea to MVP in an evening (within maybe 1 or 2 Claude 5 hour quota windows). I've done _so_ many of these where I go "hmm, this might be useful", planned the project with gemini/chatgpt free versions to a markdown project file and then sic Claude on it while I catch up on my shows. Within a few prompts I've got something workable and I can determine if it was a good idea or not…

This right here. It's pretty amazing tbh. I'm typing this comment while Claude churns on an idea I had...

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

#173

Post by kelnos »

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…

To be fair, a "baseline knowledge of the internals of a kernel module" is not that difficult to acquire.

I think a moderately-skilled developer with experience in C could have done this, with Claude's help, even if they had little or no experience with the Linux kernel. It would probably take longer to do, and debugging would be harder, but it would still be doable.

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

#174

Post by kelnos »

AdieuToLogic wrote: post #66
rmoriz wrote: post #60

Earlier quoted context omitted.

Gatekeeping is toxic. I love agents explaining me projects I don‘t know. Recently I cloned sources of Firefox and asked qwen-code (tool not significant) about the AI features of Firefox and how it‘s implemented. Learning has become awesome.

> 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 machine[0], corrupt internal data structures resulting in arbitrary data corruption, and/or cause damage to peripheral devices.

Now that's some gatekeeping right there. "Only experts can write kernel modules" is a pretty toxic attitude to have.

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

#175

Post by kelnos »

yeasku wrote: post #33
squeakywhite wrote: post #29

Earlier quoted context omitted.

The post was created to show how AI helped this person solve their particular problem - which it appeared to do successfully. Other people commenting about AI hype on the post isn't an indication that the post itself was created to hype AI, or that that the post itself is "bad".

[flagged]

> I said nobody will use the driver. But I am terrible wrong because one person will?

Yes, you are wrong. And also, if you look around in these HN comments, there's at least one person here who says they have a bunch of these tapes lying around and would love to try the driver themselves. So that's two people!

> Second, any post on hackernews is made to generate hype.

Blanket generalizations like that aren't useful. You don't and can't know any random person's motivation for posting something here.

I don't even really understand why you're commenting. The things you are saying are either just rude or unnecessary. Honestly, if you are that cynical about things posted on this site, why even bother visiting it at all?

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

#176

Post by kelnos »

codedokode wrote: post #154
codedokode wrote: post #152

LLMs are also good for writing quick experiments and benchmarks to satisfy someone's curiosity. For example, once I was wondering, how much time does it take to migrate a cache line between cores when several processes access the same variable - and after I wrote a detailed benchmark algorithm, LLM generated the code instantly. Note that I described the algorithm completely and what it did is just translated it into…

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 see that often enough too, but if I then ask it to review what it's done and look for opportunities to factor out duplicated code, it does a decent job.

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

#177

Post by kelnos »

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 comments is just staggering. I've only recently started adopting LLM coding tools, and I still remain a skeptic about the whole thing overall, but... damn. Seems like most people aren't thinking critically and are just regurgitating "durrrr LLMs bad" over and over.

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

#178

Post by kelnos »

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...

Looks like that hasn't been updated in 6 years, and only supports the 2.6.x kernel.

I doubt it would have been significantly easier to start the porting effort from that vs. the original 2.4.x source.

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

#179

Post by mettamage »

theptip wrote: post #3

A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…

I don’t have a lot of experience with your first point. I do I have a lot of experience with your second point. And I would say that you hit the nail on the head
Post reply on HN