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

[Guenter Roeck]

On 9/24/24 06:56, Maxime Ripard wrote:
> On Tue, Sep 24, 2024 at 06:37:59AM GMT, Guenter Roeck wrote:
>> 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.
>>>

FWIW, that is arguable. More and more tests are added which do add such splats,
and I don't see any hesitance by developers to adding more. So far I counted
two alone in this commit window, and that does not include new splats from
tests which I had already disabled. I simply disable those tests or don't
enable them in the first place if they are new. I did the same with the drm
unit tests due to the splats generated by the scaling unit tests, so any
additional drm unit test splats don't make a difference for me since the
tests are already disabled.

>>> 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.
> 
> Well, if that means anything, we're interested even in something
> imperfect if it solves the above case :)
> 

Maybe someone else is interested picking it up (and no need for credits).
I am buried in work and don't have the time (nor, frankly, much interest)
to revive it. Also, just for reference: The patch series touches a total
of 8 architectures, and unless I missed some I only got feedback from two
architecture maintainers. That doesn't include arm - I don't recall if it
doesn't need changes or if I never got there.

Guenter