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

Guenter Roeck linux at roeck-us.net
Tue Sep 24 13:37:59 UTC 2024


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@roeck-us.net/
> 
> 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



More information about the Intel-gfx mailing list