Three decades in kernelland [LWN.net]

At Open Source Summit Europe, LWN's Jonathan Corbet presented "Three Decades in Kernelland"; the talk provides a look at how the kernel got to where it is, what makes it successful, and what may be coming next. The video of the talk is now online for LWN readers who would like to check it out.

to post comments

Tools for kernel development

Posted Sep 11, 2025 3:43 UTC (Thu) by neilbrown (subscriber, #359) [Link] (8 responses)

Corbet suggests there is a weakness in our tool use. I wonder how many of us have useful tools we have written but never made public for whatever reason.
Does anyone have a favourite tool they would like to share, or a burning need they want a tool for?

Tools for kernel development

Posted Sep 11, 2025 6:25 UTC (Thu) by ajdlinux (subscriber, #82125) [Link] (3 responses)

Noting that I haven't yet watched the talk, so I'm taking a guess at some context here: there's also a lot of kernel development related tools that people have made public, but which are not actively maintained, not well documented, or are hard to find, and there's a lot of reinventing the wheel. I think the kernel community would be better served if we were a bit more coordinated about the tooling we create, including maintaining some things as part of the kernel project proper and documenting where other tools can be found.

Tools for kernel development

Posted Sep 11, 2025 7:32 UTC (Thu) by taladar (subscriber, #68407) [Link] (2 responses)

It might also help get the tools from "good enough for personal use" to "good enough for random kernel developer use" if there was some sort of coordinated incubation project for tooling perhaps?

Tools for kernel development

Posted Sep 11, 2025 14:45 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

What I've observed is that people write tools that are "good enough for personal use" when they need to streamline their personal process in order to get done what they're really working on. This means that the authors of such tools are unlikely to be positioned to improve or support them, because they're selected by having higher-priority tasks to do.

A coordinated incubation project for tooling would be valuable in that it could attract people who are interested in writing tools and not too busy with something else. Then the project could try to attract the people who wrote their own tools to be users (rather than maintainers or developers) of the common ones, because they'd be motivated to provide valuable user feedback even if they don't have time to write maintainable code in the project.

Tools for kernel development

Posted Sep 11, 2025 15:54 UTC (Thu) by farnz (subscriber, #17727) [Link]

I've attempted to get something like that going inside a company. Some observations so that anyone doing this for the kernel can avoid the problems I encountered.

You need a way for people who've written a "quick tool" for personal use to contribute it as-is; if you don't, the people who write their own tools today don't bother engaging with you, they just do whatever it is they did before, and you miss out on that source of feedback completely.
You're going to get a lot of drive-by contributions; someone needs to be reviewing those and fixing them up, with an emphasis on not regressing current users (since regressions in tools you depend upon cause great upset).
It's often going to be easier to copy an existing tool and improve it than to improve in-place; someone needs to prune unused tools.
Related to the previous one, you need someone to actively track down uses of superseded tools and get people onto the newer tool. This usually means a "compat" wrapper so that I can use the old tool's CLI, and it just invokes the new tool for me, with a note to tell me to upgrade. However, you can't just remove an in-use tool, even if it's down to one user, without destroying many people's confidence in your project.
Nobody, is going to do security or dependency fixes on tools they use. That's your problem now, and that's basically the thing you offer that makes it worth sending you my quick tool to improve. However, because it's now a shared tool, the blast radius of bugs increases massively; as a result, you need to be worrying about quick-and-dirty code that used to be safe, but isn't when used on the "wrong" system (most notably, are spaces allowed in paths or not?)
You are going to find out what obscure languages people still use, and you are going to have to deal with this - maybe by deeming the Perl4 version of a tool as a "requirements list", maybe by learning FORTRAN77, maybe by finding help.

Tools for kernel development

Posted Sep 12, 2025 9:27 UTC (Fri) by error27 (guest, #8346) [Link] (3 responses)

This is the tool I use to review mechanical patches. For example, if someone fixes a typo, I `cat <email.txt> | rename_rev.pl -a` this shows me which words they fixed. If they changed all the (1 << 1) shifts to BIT(1), then there is an option for that.

https://github.com/error27/rename_rev

I wrote the tool a long time ago and it's kind of crap but it's good enough for me so even though I think about re-writing it, I haven't done that yet.

As far as wish lists. I wish that I had a better replacement for cscope... There probably is one that I just haven't been using. I also have an idea that editors could be much better and more useful if they were tied together with a static analyzer.

Tools for kernel development

Posted Sep 12, 2025 14:37 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> I also have an idea that editors could be much better and more useful if they were tied together with a static analyzer.

I'm sure that Emacs has its equivalents, but ALE[1] has been quite handy with Vim (though I use NeoVim).

[1]https://github.com/dense-analysis/ale

Tools for kernel development

Posted Sep 15, 2025 11:20 UTC (Mon) by geert (subscriber, #98403) [Link] (1 responses)

I just apply the patch first, and use the --color-words option of various git commands. I found that option so useful that I created some aliases:
$ git help wdiff
'wdiff' is aliased to 'diff --color-words'
$ git help wshow
'wshow' is aliased to 'show --color-words'

Tools for kernel development

Posted Sep 15, 2025 11:57 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Indeed. I extend these with `ww` and `c` prefixes as well:

wwdiff = diff --color-words=[[:alnum:]_]+|[^[:space:]]
cdiff = diff --color-words=[^[:space:]]

`ww` does Vi-like WORD chunking while `c` is character-wise.

Great presentation!

Posted Sep 16, 2025 16:33 UTC (Tue) by lwnuser573 (subscriber, #134940) [Link]

Thanks for the excellent presentation!

Three decades in kernelland

Posted Sep 17, 2025 17:45 UTC (Wed) by jo42 (subscriber, #59640) [Link]

A question about this success story came to my mind: Can this happen again, or was it a one-off moment that enabled Linux's rise? Is there perhaps a new operating system (kernel) out there that we are ‘ignoring’?