4 ms·

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

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...

_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...