Re: [PATCH 0/2] drm: revert some framebuffer API tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/24/24 04:54, Maxime Ripard wrote:
+Guenter

On Tue, Sep 24, 2024 at 12:06:28PM GMT, Simona Vetter wrote:
On Tue, Sep 17, 2024 at 08:43:50PM +0300, Jani Nikula wrote:
The tests consistently trigger WARNs in drm_framebuffer code. I'm not
sure what the point is with type of belts and suspenders tests. The
warnings *are* the way to flag erroneous API usage.

Warnings in turn trigger failures in CI. Filtering the warnings are
error prone, and, crucially, would also filter actual errors in case the
kunit tests are not run.

I acknowledge there may be complex test cases where you'd end up
triggering warnings somewhere deep, but these are not it. These are
simple.

Revert the tests, back to the drawing board.

Yeah I think long-term we might want a kunit framework so that we can
catch dmesg warnings we expect and test for those, without those warnings
actually going to dmesg. Similar to how the lockdep tests also reroute
locking validation, so that the expected positive tests don't wreak
lockdep for real.

But until that exists, we can't have tests that splat in dmesg when they
work as intended.

It should be pretty soon:
https://lore.kernel.org/dri-devel/20240403131936.787234-1-linux@xxxxxxxxxxxx/

I'm not sure what happened to that series, but it looks like everybody
was mostly happy with it?


Major subsystem maintainers did not provide any feedback at all, and then
there came the "it is not perfect enough" feedback, so I gave up on it.

Guenter




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux