Re: [PATCH v3 kunit-next 1/2] kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results display

[Frank Rowand]

On 2/17/20 9:45 AM, Alan Maguire wrote:
> On Wed, 12 Feb 2020, Frank Rowand wrote:
> 
>> On 2/7/20 10:58 AM, Alan Maguire wrote:
>>> add debugfs support for displaying kunit test suite results; this is
>>> especially useful for module-loaded tests to allow disentangling of
>>> test result display from other dmesg events.
>>>
>>> As well as printk()ing messages, we append them to a per-test log.
>>>
>>> Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
>>> ---

< snip >

>>> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
>>> index 9242f93..aec607f 100644
>>> --- a/lib/kunit/test.c
>>> +++ b/lib/kunit/test.c
>>> @@ -10,6 +10,7 @@
>>>  #include <linux/kernel.h>
>>>  #include <linux/sched/debug.h>
>>>  
>>> +#include "debugfs.h"
>>>  #include "string-stream.h"
>>>  #include "try-catch-impl.h"
>>>  
>>> @@ -28,73 +29,91 @@ static void kunit_print_tap_version(void)
>>>  	}
>>>  }
>>>  
>>> -static size_t kunit_test_cases_len(struct kunit_case *test_cases)
>>> +size_t kunit_suite_num_test_cases(struct kunit_suite *suite)
>>>  {
>>>  	struct kunit_case *test_case;
>>>  	size_t len = 0;
>>>  
>>> -	for (test_case = test_cases; test_case->run_case; test_case++)
>>> +	kunit_suite_for_each_test_case(suite, test_case)
>>>  		len++;
>>>  
>>>  	return len;
>>>  }
>>> +EXPORT_SYMBOL_GPL(kunit_suite_num_test_cases);
>>>  
>>>  static void kunit_print_subtest_start(struct kunit_suite *suite)
>>>  {
>>>  	kunit_print_tap_version();
>>> -	pr_info("\t# Subtest: %s\n", suite->name);
>>> -	pr_info("\t1..%zd\n", kunit_test_cases_len(suite->test_cases));
>>> +	kunit_log(KERN_INFO, suite, "# Subtest: %s", suite->name);
>>> +	kunit_log(KERN_INFO, suite, "1..%zd",
>>> +		  kunit_suite_num_test_cases(suite));
>>
>> The subtest 'is a TAP stream indented 4 spaces'.  (So the old code was
>> also incorrect since it indented with a tab.)
>>
>> kunit_print_ok_not_ok() has a similar indentation issue.
>>
> 
> I'll defer to Brendan on the TAP format stuff if you don't
> mind; the aim here is to preserve existing behaviour.  I
> think it might be better to tackle TAP format issues in
> a separate patchset.

My first attempt to respond started with "That is a reasonable approach".
But on reflection, the patch is adding code that is incorrect (even if
the new code is replacing existing code that is incorrect).

If you don't want to change the spacing in patch 1/2, then please add
patch 3/3 that corrects the spacing.  That allows patches 1/3 and 2/3
to preserve existing behaviour.

Thanks,

Frank

> 
> I also updated the documentation patch in v4 (patch 3)
> to incorporate the suggested wording.
> 
> Thanks for the careful review!
> 
> Alan
>  
>>

< snip >