linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Roberts <ryan.roberts@arm.com>
To: John Hubbard <jhubbard@nvidia.com>, Mark Brown <broonie@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Shuah Khan <shuah@kernel.org>, Peter Xu <peterx@redhat.com>,
	Aishwarya TCV <Aishwarya.TCV@arm.com>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v1] selftests/mm: Log run_vmtests.sh results in TAP format
Date: Mon, 18 Dec 2023 11:32:49 +0000	[thread overview]
Message-ID: <c417dabb-d7f5-4757-be4f-26b15c3f2fd2@arm.com> (raw)
In-Reply-To: <fb91ab59-ab5c-45c4-a413-bd6c060bfcc8@nvidia.com>

On 16/12/2023 02:40, John Hubbard wrote:
> On 12/15/23 18:25, John Hubbard wrote:
>> On 12/15/23 06:28, Ryan Roberts wrote:
>> ...
>>> I've kept all the existing "pretty" output and results summary as is, it just
>>> gets a hash in front of it when TAP is enabled.
>>>
>>> so this:
>>>
>>> -----------------------
>>> running ./hugepage-mmap
>>> -----------------------
>>> Returned address is 0xffff89e00000
>>> First hex is 0
>>> First hex is 3020100
>>> [PASS]
>>> SUMMARY: PASS=1 SKIP=0 FAIL=0
>>>
>>> becomes this:
>>>
>>> TAP version 13
>>> # -----------------------
>>> # running ./hugepage-mmap
>>> # -----------------------
>>> # Returned address is 0xffff89e00000
>>> # First hex is 0
>>> # First hex is 3020100
>>> # [PASS]
>>> ok 1 hugepage-mmap
>>> # SUMMARY: PASS=1 SKIP=0 FAIL=0
>>> 1..1
>>>
>>> If you think the latter is ofensive, then I can do the wrapping as you suggest.
>>
>> I applied this and ran the tests, all while carefully reminding myself
>> to "think like a human". :) And from that perspective, to me, the output
>> is effectively the same: the leading '#' characters do not really change
>> anything, from a readability point of view.
>>
>> So IMHO you're on perfectly solid ground, if you just switch over
>> directly to this format.

Great thanks for taking a look!

>>
>> Tested-by: John Hubbard <jhubbard@nvidia.com>
>>
> 
> I should also point out that some of the subtests already attempt a TAP
> output. So now we end up with TAP-within-TAP output for those programs.

It's actually TAP-in-TAP-in-TAP if you're running from run_kselftest.sh :)

> 
> For example:
>     # -----------------------
>     # running ./madv_populate
>     # -----------------------
>     # TAP version 13
>     # 1..21
>     # # [RUN] test_prot_read
>     # ok 1 MADV_POPULATE_READ with PROT_READ
>     # ok 2 MADV_POPULATE_WRITE with PROT_READ
>     # # [RUN] test_prot_write
>     # ok 3 MADV_POPULATE_READ with PROT_WRITE
>     ...etc...
> 
> Note the double level of leading '#' characters.
> 
> Again, this is still readable enough for humans. But it should probably
> be removed in subsequent patches to the subtests.

I personally don't agree with this. It would be difficult to flatten to a single
TAP instance because the top level doesn't have a clue how many test cases the
child is running. Trying to do this will make things more fragile and less
modular. LAVA can certainly deal with nested test cases and correctly parses
everything to test case names that contain the test name at each level of
nesting. The thing I was trying to solve with this patch was that previously the
top level (run_kselftest.sh) and the bottom level (individual mm test binaries)
were using TAP, but the middle level (run_vmtests.sh) wasn't, and this was
confusing the LAVA parser.

> 
> 
> thanks,



  reply	other threads:[~2023-12-18 11:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 16:24 Ryan Roberts
2023-12-15 13:54 ` Mark Brown
2023-12-15 13:58   ` Ryan Roberts
2023-12-15 14:08     ` Mark Brown
2023-12-15 14:28       ` Ryan Roberts
2023-12-15 14:34         ` Mark Brown
2023-12-16  2:25         ` John Hubbard
2023-12-16  2:40           ` John Hubbard
2023-12-18 11:32             ` Ryan Roberts [this message]
2023-12-19  0:51               ` John Hubbard
2023-12-19  0:55                 ` John Hubbard
2023-12-19  8:33                   ` Ryan Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c417dabb-d7f5-4757-be4f-26b15c3f2fd2@arm.com \
    --to=ryan.roberts@arm.com \
    --cc=Aishwarya.TCV@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox