HN's front page magic never seizes to amaze me. If you are looking for a introduction on how to write your first kernel module, Google will return pages worth of results with blog post entries, articles and even excerpts from books such as LDD[0].
Yet this brief text gets the reward.
Don't get me wrong I absolutely root for people's efforts for popularising kernel dev, just stunned how HN works sometimes.
I think the reality is that news aggregators like HN reward short-form content; a 4 minute read is going to garner more upvotes than a page that links to 18 chapters of dense technical information. That's what the comments are for though! Thanks for linking this lwn page
It hasn’t been updated since about 2004. No idea how much has changed since then but the authors have stated they don’t update it not because it’s still accurate but because they don’t need new kernel devs and it’s a lot of work.
There are some things out of date for sure, but the bulk of it is still highly relevant.
When I was first learning to write kernel drivers, I had LDD open on one screen and the kernel source code open on the other. You can usually look for examples in the source that will help you figure out the “modern” ways of doing things. LDD is indispensable for giving you a solid footing so that you’re not wading into the Linux kernel totally unequipped.
Mention Rust for those sweet sweet internet points! (I do like Rust, however seeing features D has had for 10 years on the frontpage is a little jarring, although I am channeling that into some blog posts to get the word out)
linux-kernel-labs[1]. This looks much better if you want to dive deep. Looks more up to date then LDD though I cannot talk about the quality since I haven't actually read it.
I just found it when I put it into search. Looks more up to date then LDD though I cannot talk about the quality.
Because the code is (largely) the documentation, I recommend people to start reading kernel module sources from the bottom up.
The bottom is where the initialization happens. The further you move towards the top of the file the more specific the code becomes (register bashing and magic hardware specific values)
Additionally, I often use new drivers "published" on Phoronix as example. They are often quite simple. The complexity usually lies in the reverse engineering the hardware, not really in the driver development.
I absolutely dislike it when people decide to simply gloss over the licensing parts of code. Code licenses are a crucial component and you should really know and understand the implications of the license you pick.
This is even more important in the kernel as it changes the set of symbols available to your module.
Yes, any good guide should shown how to circumvent the Kernel’s weird form of DRM. The fact that any high resolution clock is excluded from EXPORT_SYMBOL shows that’s it’s enforced for purely political reasons.
Why images instead of text??? Images can't easily be copy-pasted as text (though in this case I really recommend re-typing).
The internet is turning into a sea of wrongly chosen media. Youtube videos are used when a small list of command lines would be enough and images are used when text would be much better.
25 comments
[ 3.2 ms ] story [ 61.8 ms ] threadDon't get me wrong I absolutely root for people's efforts for popularising kernel dev, just stunned how HN works sometimes.
[0] https://lwn.net/Kernel/LDD3/
When I was first learning to write kernel drivers, I had LDD open on one screen and the kernel source code open on the other. You can usually look for examples in the source that will help you figure out the “modern” ways of doing things. LDD is indispensable for giving you a solid footing so that you’re not wading into the Linux kernel totally unequipped.
I just found it when I put it into search. Looks more up to date then LDD though I cannot talk about the quality.
[1](https://linux-kernel-labs.github.io/refs/heads/master/)
The bottom is where the initialization happens. The further you move towards the top of the file the more specific the code becomes (register bashing and magic hardware specific values)
Additionally, I often use new drivers "published" on Phoronix as example. They are often quite simple. The complexity usually lies in the reverse engineering the hardware, not really in the driver development.
E.g. for the apple magic mouse: https://www.phoronix.com/scan.php?page=news_item&px=Apple-Ma...
And for corsair PSUs: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Co...
This is even more important in the kernel as it changes the set of symbols available to your module.
The internet is turning into a sea of wrongly chosen media. Youtube videos are used when a small list of command lines would be enough and images are used when text would be much better.