Thanks in advance for explanations.
Not the OP, but I think qemu and VirtualBox have APIs for implementing custom virtual hardware (similar to how the rest of the machine is emulated). To your kernel running in the VM, the emulated device appears as a real device.
Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page
> Which kinds of drivers you have developed this way?
As an example, this approach helped me develop a pin-controller driver[1]. I first added a new bare-bones SoC and machine to QEMU[2] to give me enough of a environment to start adding other models, such as the SoC's System Control Unit[3], which in-turn contains the registers the pin-controller driver pokes at. Using QEMU I could control the initial values in the registers and exercise the pin controller driver's implementation.
> I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place.
Not entirely - if you are writing the driver you can always pretend it succeeds! Ideally you want to get some gratification as soon as possible - if that means making some assumptions and nasty hacks, that's fine (as long as it won't smoke something!) Then start iterating to iron them out. At least, that's the kind of approach that works for me.
[1] https://lkml.org/lkml/2016/7/20/69
[2] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg...
[3] https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg070...
Yes, I guess part of the problem is figuring out how much of that you (don't) need to know.
> I think there are things we (the QEMU community) could do to make the learning curve a bit less steep but it is still definitely there...
I found the reviews were clear and insightful: In my opinion that goes a long way to making it more approachable, though I guess only if you've got so far as having a patch to be reviewed. That said, even if you don't yet have a patch, reading feedback on relevant patches from others can be just as good.