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]
Date:   Mon, 13 Mar 2023 15:59:51 +0200
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Shreeya Patel <shreeya.patel@...labora.com>,
        Paul Gazzillo <paul@...zz.com>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        Zhigang Shi <Zhigang.Shi@...eon.com>,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH v3 2/6] iio: light: Add gain-time-scale helpers

On 3/13/23 15:29, Andy Shevchenko wrote:
> On Mon, Mar 13, 2023 at 03:11:52PM +0200, Matti Vaittinen wrote:
>> On 3/13/23 14:40, Andy Shevchenko wrote:
>>> On Sun, Mar 12, 2023 at 05:08:48PM +0000, Jonathan Cameron wrote:
>>>> On Sun, 12 Mar 2023 17:06:38 +0000
>>>> Jonathan Cameron <jic23@...nel.org> wrote:
> 
> ...
> 
>>>> Ah. I forgot the tests that don't have a device so can't use devm.
>>>
>>> Why not? I have seen, IIRC, test cases inside the kernel that fakes the device
>>> for that.
>>
>> I'd appreciated any pointer for such an example if you have one at hand. (I
>> can do the digging if you don't though!)
>>
>> I am not a fan of unit tests. They add huge amount of inertia to
>> development, and in worst case, they stop people from contributing where
>> improving a feature requires test code modification(s). And harder the test
>> code is to understand, worse the unwanted side-effects. Also, harder the
>> test code is to read, more time and effort it requires to analyze a test
>> failure... Hence, I am _very_ conservative what comes to adding size of test
>> code with anything that is not strictly required.
>>
>> After that being said, unit tests are a great tool when carefully used - and
>> I assume/hope stubbing a device for devm_ tests does not add much extra...
>> But let me see if I can find an example :)
> 
> drivers/gpu/drm/tests/drm_managed_test.c ?
> 
> (somewhere underneath:
> 
>   ret = platform_driver_register(&fake_platform_driver);
> 
> which suggests... what exactly? :-)
> 

Thanks!

--Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ