Earlier quoted context omitted.
Funny, that's how I feel with Windows and Mac. I grab a machine and install Linux, and it works more or less out of the box. Maybe a few fixable quirks. And I don't use Thinkpads. I try to use Windows or macos, and it's a coin toss. Windows handling USB like hot garbage (hub balancing/buffer sizes leading to devices unable to activate, webcams glitching, input lagging at random intervals), display issues (macos doesn…
> having been a proprietary kernel driver developer for Windows, FreeBSD and Linux May I ask how you learned how to do this? I'd like to learn too! I had a great experience developing a Linux user space driver for my own laptop's LEDs. Couldn't figure out how to control the fans though.
2. Play around with embedded. You can use an arduino, but get rid of the Arduino IDE. Once you've ridded yourself from their weird environment and code in C, you're pretty close to what kernel programming is: Direct hardware control, debugging over a serial console, and if you mess up you don't get saved by a segfault.
You can upgrade to playing with ARM boards later if you want. Things like a Raspberry Pi can also be useful to boot random kernels you've built later on for HW stuff, otherwise you can use VMs. QEMU can boot a kernel file directly, which makes debugging easier.
3. Look at one of the tutorial for writing hello-world kernel modules. There's also usually smaller cleanup tasks you can do to get started submitting work. Looking at Linux and FreeBSD both can be useful, and things like Plan9 have very small kernels that can be used as reference. Linux and FreeBSD are not that different. (Windows is a pain with really weird interfaces, but it can be made to work.)
4. Find something you want to do with the kernel or fix in it.
Kernel developers aren't that common, so I imagine a lot of places are willing to train people. The first job I had doing kernel work was pretty open, and just threw minor stuff to begin with at me, e.g. "things stopped working after kernel X.Y, figure out what happened". Bisecting, testing in VMs, printk'ing a lot to compare state, stuff like that. I later ended up being the owner of the kernel drivers of all our platforms, so I guess I did okay. :)