[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c1e0924-40b6-17e1-11c3-081970484340@gmail.com>
Date: Tue, 27 Oct 2020 13:21:13 +0530
From: Arpitha Raghunandan <98.arpi@...il.com>
To: Marco Elver <elver@...gle.com>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
skhan@...uxfoundation.org, Iurii Zaikin <yzaikin@...gle.com>,
Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
KUnit Development <kunit-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-kernel-mentees@...ts.linuxfoundation.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH v3 1/2] kunit: Support for Parameterized Testing
On 27/10/20 1:14 pm, Marco Elver wrote:
> On Tue, 27 Oct 2020 at 06:14, Arpitha Raghunandan <98.arpi@...il.com> wrote:
> [...]
>>>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>>>> index a423fffefea0..16bf9f334e2c 100644
>>>> --- a/include/kunit/test.h
>>>> +++ b/include/kunit/test.h
>>>> @@ -142,6 +142,12 @@ struct kunit_case {
>>>> void (*run_case)(struct kunit *test);
>>>> const char *name;
>>>>
>>>> + /*
>>>> + * Pointer to test parameter generator function.
>>>> + * Used only for parameterized tests.
>>>
>>> What I meant was to give a description of the protocol, so that if
>>> somebody wanted, they could (without reading the implementation)
>>> implement their own custom generator without the helper macro.
>>>
>>> E.g. something like: "The generator function is used to lazily
>>> generate a series of arbitrarily typed values that fit into a void*.
>>> The argument @prev is the previously returned value, which should be
>>> used to derive the next value; @prev is set to NULL on the initial
>>> generator call. When no more values are available, the generator must
>>> return NULL."
>>>
>>
>> Oh okay. I am not sure if this is the best place to add documentation for this.
>
> I think it doesn't hurt to add, but have a look at the comment above
> this struct, which is already a kernel-doc comment. It probably makes
> sense to move the comment there to describe the new variable.
>
Alright, I will move the comment there.
> Thanks,
> -- Marco
>
Thanks.
Powered by blists - more mailing lists