From: Jani Nikula <jani.nikula@intel.com>
To: Maxime Ripard <mripard@kernel.org>,
Simona Vetter <simona.vetter@ffwll.ch>
Cc: Guenter Roeck <linux@roeck-us.net>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Carlos Eduardo Gallo Filho <gcarlos@disroot.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Jeff Johnson <quic_jjohnson@quicinc.com>
Subject: Re: [PATCH 0/2] drm: revert some framebuffer API tests
Date: Wed, 02 Oct 2024 15:10:14 +0300 [thread overview]
Message-ID: <877caqu2mx.fsf@intel.com> (raw)
In-Reply-To: <20240925-fresh-artichoke-boa-1a673f@houat>
On Wed, 25 Sep 2024, Maxime Ripard <mripard@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
>> 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.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-10-02 12:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-17 17:43 [PATCH 0/2] drm: revert some framebuffer API tests Jani Nikula
2024-09-17 17:43 ` [PATCH 1/2] Revert "drm/tests: Add test for drm_framebuffer_free()" Jani Nikula
2024-09-17 17:43 ` [PATCH 2/2] Revert "drm/tests: Add test for drm_framebuffer_init()" Jani Nikula
2024-09-17 19:01 ` ✗ Fi.CI.SPARSE: warning for drm: revert some framebuffer API tests Patchwork
2024-09-17 19:10 ` ✓ Fi.CI.BAT: success " Patchwork
2024-09-18 8:44 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-09-24 10:06 ` [PATCH 0/2] " Simona Vetter
2024-09-24 11:54 ` Maxime Ripard
2024-09-24 13:37 ` Guenter Roeck
2024-09-24 13:56 ` Maxime Ripard
2024-09-24 15:09 ` Guenter Roeck
2024-09-24 15:56 ` Jani Nikula
2024-09-24 16:35 ` Guenter Roeck
2024-09-24 16:57 ` Maxime Ripard
2024-09-24 17:37 ` Guenter Roeck
2024-09-25 9:41 ` Jani Nikula
2024-09-25 12:59 ` Maxime Ripard
2024-09-25 15:57 ` Guenter Roeck
2024-09-25 11:52 ` Simona Vetter
2024-09-25 13:05 ` Maxime Ripard
2024-09-25 16:04 ` Guenter Roeck
2024-09-26 7:05 ` Maxime Ripard
2024-10-02 12:10 ` Jani Nikula [this message]
2024-10-03 12:04 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877caqu2mx.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gcarlos@disroot.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux@roeck-us.net \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=quic_jjohnson@quicinc.com \
--cc=simona.vetter@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.