Nathan Lynch <nath...@linux.ibm.com> writes: > Michael Ellerman <m...@ellerman.id.au> writes: >> >> It would also be *really* nice if we had some unit tests for this >> parsing code, it's demonstrably very bug prone. > > Can you say more about what form unit tests could take? Like some self > tests that run at boot time, or is there a way to run the code in a user > space test harness?
It depends. A userspace selftest is ideal as it's the easiest option for people to run, ie. they just have to build a user program. There's also CI systems setup to run the kernel selftests automatically. See eg. tools/testing/selftests/powerpc/vphn/vphn.c We also have boot time tests, they are good for code that we want to test in the kernel proper, or that are hard to extract into a userspace program. Most of those are configurable, so testing them requires someone to enable the appropriate CONFIG_FOO and build & boot that kernel. That reduces coverage obviously. See eg. arch/powerpc/lib/code-patching.c These days there's also kunit, which is a "proper" way to do kernel unit tests. They get built into the kernel but then there's some support for running those like a user program using UML on x86. On powerpc we'd have to boot the kunit enabled kernel on hardware or in qemu to exercise the tests. So they're essentially just boot time tests but with some nicer infrastructure vs doing it all by hand like we used to. In this case the actual function we want to test could be trivially built into a userspace program, but the underlying device tree helpers probably can't be. eg. drivers/of/property.c is quite large and contains quite a few things, we'd need to shim quite a bit to get that building in userspace I suspect, which then becomes a maintenance burden. So this is probably a good candidate for a kunit test, though I haven't personally written/converted any tests to kunit so I can't say exactly how easy that is. cheers