lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ