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

[Maxime Ripard]

On Wed, Oct 02, 2024 at 03:10:14PM GMT, Jani Nikula wrote:
> On Wed, 25 Sep 2024, Maxime Ripard <mripard at kernel.org> wrote:
> > On Wed, Sep 25, 2024 at 01:52:02PM GMT, Simona Vetter wrote:
> >> I think for at least drm the consensus is clear, we won't have kunit tests
> >> that splat.
> >
> > Where was that ever discussed?
> 
> Well, where was it ever agreed that it's okay for drm kunit tests to
> emit warnings? :p

One policy is upstream, the other isn't. And it does seem like the
consensus towards downstream patches and policies is pretty well
established.

And I wasn't the one claiming that there's a consensus to begin with, so
I don't see why I should prove anything?

> >> Personally I really don't see the point of unit tests that are
> >> somewhere between unecessarily hard or outright too much pain to
> >> deploy in a test rig: Either you don't run them (not great), or you
> >> filter splats and might filter too much (not great either) or you
> >> filter as little as possible and fight false positives (also kinda
> >> suboptimal).
> >
> > Or you don't do any of that, and just rely on the canonical way to run
> > kunit test and trust it's going to pass tests that do indeed pass, and
> > fail / warn on those that don't.
> 
> That still doesn't address code being tested emitting *unexpected*
> warnings.

Then make kunit report a warning / failure when there's an unexpected
warning splat.


At the end of the day, the discussion is that we already require for for
each committer to:

  - Apply patches
  - Check for checkpatch issues
  - Solve potential conflicts
  - Make sure it compiles on three different architectures, with huge defconfigs
  - Make sure the unit tests still pass

I'm not going to add "and grep through the output of those 1000-ish
tests for a warning" to that list.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20241003/405cf013/attachment.sig>