Re: Enabling additional KUnit tests in KernelCI?
Mark Brown <[email protected]> Thu, 12 Mar 2026 23:34:51 +0000
| Newsgroups | dev.linux.lists.kernelci |
|---|---|
| Message-ID | <[email protected]> |
--RfluQZs15kmIELpL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 12, 2026 at 02:51:45PM -0700, Eric Biggers wrote: > On Thu, Mar 12, 2026 at 08:21:26PM +0000, Mark Brown wrote: > > We should be running KUnit tests: > > https://github.com/kernelci/kernelci-pipeline/blob/a3b622cfee641e26bed1906b29ed7065bee45921/config/jobs.yaml#L2153 > > https://github.com/kernelci/kernelci-pipeline/blob/a3b622cfee641e26bed1906b29ed7065bee45921/config/scheduler.yaml#L1750 > Which ones? Does anything need to be done to add new tests to the list? > Note that even if "all" tests are being run (via > CONFIG_KUNIT_ALL_TESTS=y), that includes only the tests whose > dependencies are met. There can be additional kconfig dependencies. Whatever is enabled by the KUnit runner tools/testing/kunit/kunit.py (which makes x86_64 a bit of an unfortunate choice given how slim theilr defconfig is). The theory is that the KUnit configs will do the right thing, it looks like we're not currently pasing --alltests though which we should - I'll look at a patch for that tomorrow. If you need arch specific options that aren't enabled by the platform's defconfig that gets a bit awkward. > > though like you say something seems to be going AWOL with at least the > > reporting, I can't see any results either. The job that's configured > > there is to run on x86_64 rather than UML so is probably what you're > > looking for in terms of the tests? > The kernel has optimized crypto and/or CRC code for the following > architectures: arm, arm64, mips, powerpc, riscv, s390, sparc, x86. In > many cases there's also a finer division based on CPU features. > So I'm looking for testing on as many platforms as possible. But some > x86_64 platform is a good start, certainly better than nothing. The KUnit runner uses qemu as standard which I guess is probably fine for an initial pass, we would need to do a bunch more plumbing to run on actual hardware and pull the results out. We'd also be restricted by what's available to us, at the minute we've got arm, arm64, riscv and x86 systems with a bit of an embedded focus. --RfluQZs15kmIELpL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmmzTZsACgkQJNaLcl1U h9CH9Qf8CSlZcjTsoAFDzuGgeeqydONo6hEw/xauyBIen59zvdpibNC+kLbPfMMW qYmEbcrR5mcjlDsevw3euteI2aa7TrmQ+X/4CaspUQZA7OS6dZKmoYGZJEzgMpTF fKmVhlKHzMPDZwDBB4mWhhU+5JK4wxl1piMh8msNRX5g29Mm8g9cinOlJZ0mJ0qt gXliC0ef/AMXYxSvBtgrS/jez4PKXyFNNiSywEvCyVfu6nm4ZM+vwkpKPt8Ch+3K qwbSgEh34UeWmSEXijaOeUEl2wXn9uRbqTbg1g59qFPDJnjt9hCrP9BQTu5uXi4C GvrAmB0Q0kvdobGNLJ/LioFgmFHBGA== =ZNCA -----END PGP SIGNATURE----- --RfluQZs15kmIELpL--