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

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

 



+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?

Maxime

Attachment: signature.asc
Description: PGP signature


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

  Powered by Linux