4 ms·

An approach that's worked well for me was to first hack qemu to add some new (emulated) hardware, then write the kernel drivers using qemu to test (followed by

by amboar 10y ago

An approach that's worked well for me was to first hack qemu to add some new (emulated) hardware, then write the kernel drivers using qemu to test (followed by running on the hardware). That does leave you with two problems instead of one, but is quite flexible when you are trying to track down bugs and can increase your hack/compile/test velocity.

andrey_utkin 10y ago
Which kinds of drivers you have developed this way? I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place. You say you had "emulated" hardware - what this means, exactly? Thanks in advance for explanations.
- _pmf_ 10y ago
  > I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place. 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.
- amboar 10y ago
  > You say you had "emulated" hardware - what this means, exactly? Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page 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 https://lkml.org/lkml/2016/7/20/69 [2] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03667.html https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg... [3] https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07042.html https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg070...
pm215 10y ago
As you say, now you have two million-line codebases to understand instead of one :-) 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...
- amboar 10y ago
  > As you say, now you have two million-line codebases to understand instead of one :-) 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.

by amboar 10y ago

andrey_utkin 10y ago

Which kinds of drivers you have developed this way? I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place. You say you had "emulated" hardware - what this means, exactly? Thanks in advance for explanations.

_pmf_ 10y ago
> I guess it's not possible to test driver code unless probe() succeeds, which requires actual hardware to be in place. 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.
amboar 10y ago
> You say you had "emulated" hardware - what this means, exactly? Software pretending it is hardware, for example QEMU: http://wiki.qemu.org/Main_Page 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 https://lkml.org/lkml/2016/7/20/69 [2] https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03667.html https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg... [3] https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07042.html https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg070...

pm215 10y ago

As you say, now you have two million-line codebases to understand instead of one :-) 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...

amboar 10y ago
> As you say, now you have two million-line codebases to understand instead of one :-) 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.