On Mon, Nov 7, 2022 at 10:38 AM Michał Winiarski <michal.winiarski@xxxxxxxxx> wrote: > > On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote: > > Hi, > > > > I'm facing a couple of issues when testing KUnit with the i915 driver. > > > > The DRM subsystem and the i915 driver has, for a long time, his own > > way to do unit tests, which seems to be added before KUnit. > > > > I'm now checking if it is worth start using KUnit at i915. So, I wrote > > a RFC with some patches adding support for the tests we have to be > > reported using Kernel TAP and KUnit. > > > > There are basically 3 groups of tests there: > > > > - mock tests - check i915 hardware-independent logic; > > - live tests - run some hardware-specific tests; > > - perf tests - check perf support - also hardware-dependent. > > > > As they depend on i915 driver, they run only on x86, with PCI > > stack enabled, but the mock tests run nicely via qemu. > > > > The live and perf tests require a real hardware. As we run them > > together with our CI, which, among other things, test module > > unload/reload and test loading i915 driver with different > > modprobe parameters, the KUnit tests should be able to run as > > a module. > > Note that KUnit tests that are doing more of a functional/integration > testing (on "live" hardware) rather than unit testing (where hardware > interactions are mocked) are not very common. > Do we have other KUnit tests like this merged? I don't think we have other tests like this. > Some of the "live tests" are not even that, being more of a pure > hardware tests (e.g. live_workarounds, which is checking whether values > in MMIO regs stick over various HW state transitions). > > I'm wondering, is KUnit the right tool for this job? The main focus of KUnit is for hw-independent tests. So in theory: no. But I can imagine it could be easier to write the validation via KUNIT_EXPECT_EQ and friends as opposed to writing your own kernel module w/ its own set of macros, etc. So my first thought is: "if it works, then you can try using it." (Might want to take steps like make sure they don't get enabled by CONFIG_KUNIT_ALL_TESTS=y). Talking with David, he seems to have echoed my thoughts. David also suggested that maybe the test could use a fake of the hw by default, but have an option to run against real hw when available. I think that sounds like a good chunk of work, so I don't know if you need to worry about that. Daniel
