A kernel unit-testing framework
A kernel unit-testing framework
Posted Mar 4, 2019 19:32 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: A kernel unit-testing framework by pbonzini
Parent article: A kernel unit-testing framework
However lots of other devices most definitely can be simulated.
Simulation also doesn't have to be perfect to be useful. Just something good enough will suffice.
Posted Mar 4, 2019 21:13 UTC (Mon)
by pizza (subscriber, #46)
[Link]
"All models are wrong. Some are useful."
But the "useful" threshold varies widely depending on what you're trying to accomplish.
The majority of my headaches with respect to device drivers was due to the hardware not working the way it was documented. Spurious interrupts, clock phasing, interactions/collisions with shared resources, subtle sleep/wake sequencing issues, sensitivity to environmental conditions (eg clocks drifting between -40C -> 85C), dma peripheral quirks, workarounds for things fixed in later revisions.. and so forth.
Granted, I also had plenty of headaches due to the upper stacks not behaving as specified either. Or perhaps I should say significantly underspecified -- While it was actually well-tested (unit and system-level) the tests were written from the same incorrect/incomplete set of spherical-cow specifications/assumptions.
Posted Mar 4, 2019 22:51 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
USB would only be practical if you also emulated all the broken devices around to ensure they don't regress. Same for the "generic" drivers like AHCI or SDHCI.
Some mock devices are there, for example scsi_debug, the tests are in user space rather than kernel.
Posted Mar 14, 2019 3:22 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A kernel unit-testing framework
A kernel unit-testing framework
A kernel unit-testing framework
