Speaker
Description
The kunit.py tool currently spreads its configuration across three places: kunitconfig files, which contain Kconfig entries for the kernel being tested; qemu_config python scripts, which configure architecture- and emulator-specific options; and command-line arguments, which specify what is being done (building, testing, parsing, etc.), and any options specific to the run (filters, build options, output configuration, etc.)
This means that, in order to completely configure a test run, three different configuration sources need to be managed, all of which are in different formats, and one of which isn’t even a file.
If we can implement a combined configuration format, this will not only simplify configuring KUnit tests, but also allow enhancements to kunit.py which manage configurations more explicitly. With first-class configurations, kunit.py could — for example — support running multiple different configurations as part of a single execution.
Would this be useful, and if so, how should we do it? In particular:
- Should we extend the Kconfig-based ‘kunitconfig’ files with additional configuration lines?
- Would a python-based configuration (more like the qemu_config files) be sufficiently simpler?
- How important is maintaining compatibility with existing configs (it shouldn’t be hard to do so)?
- Is doing multiple test runs from within kunit.py useful? (And, if not, are people doing this using other scripts/CI systems?)
- If so, how should results be handled? We can merge KTAP results (but it’s trickier to do so in a way which preserves the streaming nature of results).
- What else can’t be expressed in existing KUnit configurations which would be useful?