On 2026-08-25 at 06:04 +1000, John Hubbard <[email protected]> wrote... > On 8/24/26 12:34 PM, Danilo Krummrich wrote: > > On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote: > >> include/uapi/drm/nova_drm.h | 27 +++++++++++++++++++++++++++ > > > > Btw. I think it would be nice to have project to play around with and write > > tests directly on top of the uAPI before we can run the big test suites. > > Yes, I think it's reasonable to do something like that. Seeing a new API > from both sides, caller and callee, is always illuminating during review, > for one thing.
Yes, I had meant to do this so thanks for the reminder. You can of course see the other side of the API here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352 But that's a user of the UAPI rather than a tester of it which makes it hard to exercise everything or specific parts of the API. I did actually end up writing my own standalone test case for these, similar to [1] but never got around to tidying it up and posting it. Looking at [1] it seems reasonable as a simple stand-alone test so I will do that ahead of the next revision for this series. > > > > When I implemented the VM_BIND uAPI for nouveau I used IGT for this (but > > didn't > > enjoy it too much). It turned out to be very useful to test and benchmark > > the > > implementation before being able to complete VK CTS. > > > > When I sent the first nova-drm skeleton, I also submitted [1]; maybe we can > > extend this further accordingly? > > > > I'm also open for other ideas, but I'd really like to have something like > > this > > as we develop nova-drm. > > > > [1] https://gitlab.freedesktop.org/dakr/drm-test > > I was thinking about where this sort of thing should go, and this > location seems as good, or slightly better than the main alternatives, > to get started anyway. > > Alternatives include: > > 1) The kernel's kselftests (tools/testings/selftests). These are > helpful in many cases, but some minor issues include: Yeah, I don't think these style of tests belong in kselftests if only because they're never going to be self-contained as at a minimum they will require specific HW. It might make sense for unit-test style things, but I (think) Rust-for-Linux already has that covered. > a) Oddly tight coupling to kernel code, even though the whole > point of these is to exercise the kernel from user space. > (Otherwise, these days one would use KUnit.) I've personally > working on mitigating the coupling-induced problems and > ran into other, bigger problems along the way, such as: > > b) Confused build system and an arguably wrong way of invoking > the tests (from Make(1) !). > > 2) Some other github-like location to host user space tests for > nova. The idea is, do we want to set up a well-known location > that people should keep updated? Or let a thousand github > small test sites bloom? We obviously can't stop a thousand small test sites blooming if people create them, but I think it would be good to establish a well-known location for core Nova developers to contribute to at least. > thanks, > -- > John Hubbard >
