On Mon, 5 May 2025 at 03:02, Miguel Ojeda <miguel.ojeda.sando...@gmail.com> wrote: > > On Sun, May 4, 2025 at 8:39 PM Tamir Duberstein <tam...@gmail.com> wrote: > > > > One example is > > https://github.com/torvalds/linux/blob/59c9ab3e8cc7f56cd65608f6e938b5ae96eb9cd2/tools/testing/radix-tree/xarray.c. > > > > It might be that these are necessary because the xarray tests don't > > use kunit, and so are pretty inconvenient to run. As you might have > > guessed, I discovered these host tests when my patch porting the > > xarray tests to kunit broke the host-side build :( > > It can be useful to have some tests as independent userspace things > (i.e. outside KUnit-UML) to use other tooling on it, but I think for > such cases we would want to have a way to use the tests from userspace > without having to remove them from being KUnit tests too, since we > definitely want to test them in the actual kernel too. > > David et al. can probably tell us more context, e.g. I may be missing > some plans on their side here. For instance, for Rust, we wanted to > eventually have a way to tag stuff as kernel vs. host etc., but that > is longer term.
Yeah, this ultimately boils down to a combination of which tradeoffs are best for a given test, and personal preference. KUnit definitely has the advantage of being more a more "accurate" test in a kernel environment — particularly if you're cross-compiling — but is a bit slower and more bloated (due to having the whole kernel), and therefore a bit more difficult to debug. In an ideal world, most tests would be able to be compiled either as a host-side, standalone test or as a KUnit test. There are some (sadly lower-priority) plans to support this more with C code by having a standalone implementation of the KUnit API, and things like the automatic conversion of, e.g., assert!() macros into their KUnit equivalent could help if we wanted to try something similar on the Rust side. But, as you point out, that sort of tagging of tests is really a longer-term goal. In the meantime, my strategy has been to encourage KUnit for new tests, or ports where it's not going to break existing workflows too much, but ultimately to defer to the maintainer of the tests / code being tested if they've got strong opinions. (Of course, I am biased in KUnit's favour. :-)) -- David
smime.p7s
Description: S/MIME Cryptographic Signature
