Speaker
Description
Unit testing common library code is (relatively) easy, but drivers often deal with a lot of global state, both in code and in hardware. New features like static stubbing go some way towards making this easier, but a lot of work still goes into making "fake devices".
There are still many open questions, however:
- Are the existing tools helping? Is there something obviously missing?
- Are UML features like LOGIC_IOMEM a good path forward?
- How should drivers make a fake 'struct device'? Via a platform_device (possibly with devicetree support), root_device, or a new kunit_device?
- There are lots of ways of managing resources for tests (kunit_resource, KUnit actions, devres/devm_ APIs). What should we use, when?
- How do we deal with callbacks, threads, etc, with KUnit contexts?
- How to support other safety/reliability/testing opportunities like hardware fuzzing and Rust?
