[LittleDan]

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.