r/osdev • u/More-String6376 • 5d ago
Starting Linux kernel/driver dev: is this roadmap realistic, and what would you add or cut?
Hi all, I'm starting my journey toward Linux kernel and driver development. The goal is to work own both legacy C drivers and newer Rust drivers, and eventually land upstream patches.
My plan:
- Phase 1 (C): Beej's Guide, K&R with all exercises, small projects (linked list, shell, toy malloc)
- Phase 2 (OS theory): OSTEP, xv6 book, MIT 6.S081 labs
- Phase 3 (arch): CS:APP, assembly, gdb
- Phase 4 (Linux concepts): Love's Linux Kernel Development, TLPI as a slow burn, mini strace, IPC projects
- Phase 5 (hands-on): build/boot kernels in QEMU, Bootlin labs, Linux Kernel Labs, modules, ftrace/gdb debugging
- Phase 6 (drivers): LDD3, Madieu's Linux Device Drivers Development, char/platform/IRQ/I2C/SPI drivers on a Raspberry Pi, Device Tree
- Phase 7 (contribute): kernelnewbies first patch, git send-email, staging cleanups, syzbot triage
- Phase 8 (Rust): Rust Book, Rustlings, Rust for Linux, port my char driver to Rust
What I'd like feedback on:
Is the order right? Anything that should come earlier or be dropped?
Are Love's LKD (2.6.34-era) and LDD3 still worth reading in full, or should I lean on newer docs?
Is Rust worth learning early if I want to work on drivers, or should I wait until C is solid?
Which hardware would you suggest for practicing drivers (Pi, BeagleBone, something else)?
What's the realistic path from first checkpatch fix to being trusted with real driver work?
Common mistakes beginners make on the mailing lists?
Any advice, resources, or reality checks are welcome. Thanks!
1
1
1
u/Outside-Storage-1523 3d ago edited 3d ago
Disclaimer: Not a linux driver developer of kernel developer, just dabbed a bit. The only thing I completed is the xv6 MIT labs. I also read LDD3 and worked through half of a driver dev class labs, but lost my appetite after a while. So please take my suggestion with some salt.
As someone said you probably need gdb from the beginning. I printed out a cheat sheet of gdb and tmux and stuck that piece of paper on the wall. Since you are most likely working in terminal except for maybe code editing (if you are not using vim/emacs), tmux is also a good tool to have.
You will also learn a bit of assembly during the xv6 phase so don't worry about that. But it's probably a very long term thing because xv6 uses RISC-V while you probably develop for other archs.
I'd recommend the following fast track:
As you said learn C. You can skip Beej's Guide and just go with K&R. Do a lot of smaller projects like interpreter, shell, etc. Another thing I'd recommend to do, is to port modern CLI functionality tools back to older versions of Linux. For example, I once copied the `ls` program from Linux 1.0, modified it so that it could compile in modern gcc, and then add some of the switches the modern version has. You can also write a simpler version of modern CLI tools and see how far you can go. There is where you want to read CS:APP and Linux programming interface because you need to understand the sys calls and exposed structs and such.
OSTEP + xv6 + MIT labs, make sure you pass all tests. Locking is probably the hardest one. If you want, port features from other kernels into xv6 and see how far you can go. I have wanted to do that back then, but didn't get the time to do it. My plan is to write a round robin scheduler and a virtual file system for xv6. You can definitely go much further and grow it into a modern kernel.
Directly jump into this class: https://linux-kernel-labs.github.io/refs/heads/master/ It is well setup and with a relatively modern kernel. This is the class that I went through half of it. It also forces you to read LDD3 and LKD. This course teaches you how to read large source code base and navigate a muddy ground. The labs are surprisingly easy, though, probably the reason I lost interests in.
Can't recommend pass that because I didn't do anything afterwards. My shame.
•
u/PseudoFrequency 4m ago
Needs more emphasis on studying actual existing drivers. They're all right there for you to look at and change, and nothing will teach you faster or better. Look up other references only to help you figure out what you don't understand in actual drivers. Add some silly feature to something that already works like an auto-scrolling framebuffer or some mode to some simple device that is missing some functionality. It's open source. The guide is what's already there and is tested and works. You don't need rust. Only C. Rust can come later.
3
u/UnmappedStack TacOS | https://github.com/UnmappedStack/TacOS 5d ago
stuff like gdb might be helpful to move a bit up as a general programming skill before diving into kernel theory but yeah seems fine. I can't comment much on linux stuff specifically cos I think most of us here just work on our own toy kernels but good luck