Having a goal like getting a specific piece of hardware working is a great motivator. It might also be a bit intimidating when it comes to getting started.
For me the best way to get started into something like this is to spend lots of time reading the code to familiarize yourself with how the different components of the kernel work and fit together, and also to get really familiar with the tools at your disposal.
This is a set of things you can practice:
- Start reading the code. Maybe even at Main.
- Practice using the kernel debugger.
- Add new kernel debugger commands, even if they are just throw away, to help you figure out how to introspect the state of the system.
- Add panic() calls into different parts of the kernel, which will trap the system in the debugger in a way that’s usually resumable, so you can trace through different parts of the code that are a little hard to understand (like some object which contains members which are function pointers and it isn’t clear what they are being set to in the context that interests you).
- Get familiar with the tracing functionality built into the kernel. Add some tracing statements using dprintf() or the existing TRACE() macro in whatever module you’re looking at and use the “traced” command in the debugger to see them.
- Get a working setup that lets you build and install the whole system onto a separate partition that you can boot from. Like “HAIKU_INSTALL_DIR=/TestInstall jam -q -j8 @install.” Make sure you can reliably install onto that partition and select it from the boot loader. That makes it easy to make a change and test with the whole system without breaking your dev environment install.
- Learn how to blacklist kernel add-ons. Build the add-on from source and install it in ~/config/non-packaged/add-ons/kernel/drivers. That’s an easy way for you to build a new driver and test it without installing the whole system, and if you make a mistake, you can disable user add-ons from the boot loader.
Anyway, everybody’s different, but that’s usually my approach. Even without learning much about the hardware itself, you might end up finding bugs just reading the code and adding extra tracing.
After spending time tracing through the code the puzzle pieces will start to fit together in your head and it will be easier to read the driver code that exists now. Then you can find reference material that is out there on the Internet to help you understand how to support some currently unsupported hardware. Or learn how to use a logic analyzer.
Also, sometimes qemu already has code for simulating the kind of device you are trying to support, which will at least give you an easy way to test. And qemu also has nice tools for tracing what happens in the virtual device. You can use that to trace Windows or Linux or some other operating system to see how their driver communicates with the hardware.