4 ms·

Do most kernel programmers start out working on their regular daily-use machine? My only experience is with an embedded linux environment, and I would probably

Do most kernel programmers start out working on their regular daily-use machine? My only experience is with an embedded linux environment, and I would probably recommend starting with something like a RPi so that your environment is easy to restore if you mess something up. I also recommend "Linux Device Drivers" from O'Reilly. http://lwn.net/Kernel/LDD3/ http://lwn.net/Kernel/LDD3/

sophacles 12y ago
Whenever I do kernel stuff, it happens in a VM, limited to a subset of the cores available on the machine. That way when I inevitably bork something, I can just forcibly stop it. Another trick I've used is making as much of my core logic as possible happen in functions that are called from the kernel hooks, rather than in the kernel hooks. Then you can test a ton of it in userland to handle basic logic and flow control bugs, finally porting the code to the module. To help with this, it sometimes is actually faster to copy some of the kernel routines you use to a different .c file and change things like kprintf and kmalloc for the userland versions. It isn't going to be a perfect port, but it helps get some of the complex stuff out of the way where you have your familiar userland tools. All that said - I've only dabbled in the kernel a little, there are probably better ways that someone can chime in on.
- solarexplorer 12y ago
  Keeping the complex stuff out of the kernel is good advice. (and not just during development)
  - sophacles 12y ago
    True! Unfortunately it's sometimes unavoidable. The specific case I was remembering involved writing a qdisc... it was actually more complex to move that out of the kernel via nf_queue than to just do it in-kernel. (At least some parts of it.)
- sitkack 12y ago
  Idea: sysctl/ioctl rest interface so one can drive the new kernel module from the host vm.
mikevm 12y ago
> I also recommend "Linux Device Drivers" from O'Reilly. http://lwn.net/Kernel/LDD3/ http://lwn.net/Kernel/LDD3/ That book is a little out of date nowdays. They're working on LDD4: http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/dp/1449371612 http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/... but oddly, it's based on kernel version 3.2, which by the time the book will be released is also going to be out of date.
userbinator 12y ago
If you're doing something with a device driver, there's not much alternative, since some hardware tends to get into a state where only a hard reset will fix it. Save and sync often, and have only the bare-minimum of processes running.
LittleDan 12y ago
I agree, that's a great book to start with. When I started out programming the Linux kernel, I thought I had to understand everything and I hated the book for not going into detail on how things worked. But really, I just had to start changing code and running it, and I became a Linux kernel programmer. Now I see that I just needed to know the basic roadmap, and the rest comes from reading code and experimentation. It doesn't matter much if the book is a little outdated; the core concepts stay in place for a while. Another book I'd recommend starting with is The Linux Programming Interface. You can write programs for a while without getting to the kernel/userspace boundary, but this is essential to understand if you're going to write user-facing code (e.g., a driver). It's just like the article said--just a big, annoying to debug C program. If you understand pointers, you can learn how to program the Linux kernel. Programming in the Linux kernel has been a really fun learning experience for me. It's nice, if intimidating, how you can just do everything--there are no hard abstraction boundaries, you can read all the source and call into any part of the kernel without going through hoops. I've developed the Linux kernel with two machines, a development machine and a headless machine that I'm ssh'ing into (actually, a bunch of those--makes testing go faster). VMs aren't really an option for device drivers, but if you run your code on your development machine, you waste a lot of time.

sophacles 12y ago

Whenever I do kernel stuff, it happens in a VM, limited to a subset of the cores available on the machine. That way when I inevitably bork something, I can just forcibly stop it. Another trick I've used is making as much of my core logic as possible happen in functions that are called from the kernel hooks, rather than in the kernel hooks. Then you can test a ton of it in userland to handle basic logic and flow control bugs, finally porting the code to the module. To help with this, it sometimes is actually faster to copy some of the kernel routines you use to a different .c file and change things like kprintf and kmalloc for the userland versions. It isn't going to be a perfect port, but it helps get some of the complex stuff out of the way where you have your familiar userland tools. All that said - I've only dabbled in the kernel a little, there are probably better ways that someone can chime in on.

solarexplorer 12y ago
Keeping the complex stuff out of the kernel is good advice. (and not just during development)
- sophacles 12y ago
  True! Unfortunately it's sometimes unavoidable. The specific case I was remembering involved writing a qdisc... it was actually more complex to move that out of the kernel via nf_queue than to just do it in-kernel. (At least some parts of it.)
sitkack 12y ago
Idea: sysctl/ioctl rest interface so one can drive the new kernel module from the host vm.

mikevm 12y ago

> I also recommend "Linux Device Drivers" from O'Reilly. http://lwn.net/Kernel/LDD3/ http://lwn.net/Kernel/LDD3/ That book is a little out of date nowdays. They're working on LDD4: http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/dp/1449371612 http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/... but oddly, it's based on kernel version 3.2, which by the time the book will be released is also going to be out of date.

userbinator 12y ago

If you're doing something with a device driver, there's not much alternative, since some hardware tends to get into a state where only a hard reset will fix it. Save and sync often, and have only the bare-minimum of processes running.

LittleDan 12y ago

I agree, that's a great book to start with. When I started out programming the Linux kernel, I thought I had to understand everything and I hated the book for not going into detail on how things worked. But really, I just had to start changing code and running it, and I became a Linux kernel programmer. Now I see that I just needed to know the basic roadmap, and the rest comes from reading code and experimentation. It doesn't matter much if the book is a little outdated; the core concepts stay in place for a while. Another book I'd recommend starting with is The Linux Programming Interface. You can write programs for a while without getting to the kernel/userspace boundary, but this is essential to understand if you're going to write user-facing code (e.g., a driver). It's just like the article said--just a big, annoying to debug C program. If you understand pointers, you can learn how to program the Linux kernel. Programming in the Linux kernel has been a really fun learning experience for me. It's nice, if intimidating, how you can just do everything--there are no hard abstraction boundaries, you can read all the source and call into any part of the kernel without going through hoops. I've developed the Linux kernel with two machines, a development machine and a headless machine that I'm ssh'ing into (actually, a bunch of those--makes testing go faster). VMs aren't really an option for device drivers, but if you run your code on your development machine, you waste a lot of time.