[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93969920-b5ed-ff15-48d4-02e2f9c23505@suse.de>
Date: Fri, 23 Sep 2022 12:30:09 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Javier Martinez Canillas <javierm@...hat.com>,
Maxime Ripard <maxime@...no.tech>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Ben Skeggs <bskeggs@...hat.com>,
David Airlie <airlied@...ux.ie>,
Maxime Ripard <mripard@...nel.org>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Emma Anholt <emma@...olt.net>,
Karol Herbst <kherbst@...hat.com>,
Samuel Holland <samuel@...lland.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Daniel Vetter <daniel@...ll.ch>, Lyude Paul <lyude@...hat.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
Chen-Yu Tsai <wens@...e.org>
Cc: Dom Cobley <dom@...pberrypi.com>,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
Phil Elwell <phil@...pberrypi.com>,
nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Mateusz Kwiatkowski <kfyatek+publicgit@...il.com>,
Hans de Goede <hdegoede@...hat.com>,
Noralf Trønnes <noralf@...nnes.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-sunxi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 13/33] drm/client: Add some tests for
drm_connector_pick_cmdline_mode()
Hi
Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
> On 9/23/22 11:15, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.09.22 um 16:25 schrieb Maxime Ripard:
>>> drm_connector_pick_cmdline_mode() is in charge of finding a proper
>>> drm_display_mode from the definition we got in the video= command line
>>> argument.
>>>
>>> Let's add some unit tests to make sure we're not getting any regressions
>>> there.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@...no.tech>
>>>
>>> diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c
>>> index bbc535cc50dd..d553e793e673 100644
>>> --- a/drivers/gpu/drm/drm_client_modeset.c
>>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>>> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev *client, int mode)
>>> return ret;
>>> }
>>> EXPORT_SYMBOL(drm_client_modeset_dpms);
>>> +
>>> +#ifdef CONFIG_DRM_KUNIT_TEST
>>> +#include "tests/drm_client_modeset_test.c"
>>> +#endif
>>
>> I strongly dislike this style of including source files in each other.
>> It's a recipe for all kind of build errors. Can you do something else?
>>
>
> This seems to be the convention used to test static functions and what's
> documented in the Kunit docs: https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
That document says "...one option is to conditionally #include the test
file...". This doesn't sound like a strong requirement.
>
> I agree with you that's not ideal but I think that consistency with how
> it is done by other subsystems is also important.
>
>> As the tested function is an internal interface, maybe export a wrapper
>> if tests are enabled, like this:
>>
>> #ifdef CONFIG_DRM_KUNIT_TEST
>> struct drm_display_mode *
>> drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
>> {
>> return drm_connector_pick_cmdline_mode(connector)
>> }
>> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
>> #endif
>>
>> The wrapper's declaration can be located in the kunit test file.
>>
>
> But that's also not nice since we are artificially exposing these only
> to allow the static functions to be called from unit tests. And would
> be a different approach than the one used by all other subsystems...
>
There's the problem of interference between the source files when
building the code. It's also not the same source code after including
the test file. At a minimum, including the tests' source file further
includes more files. <kunit/tests.h> also includes quite a few of Linux
header files.
IMHO the current convention (if any) is far from optimal and we should
consider breaking it.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)
Powered by blists - more mailing lists