From: Thomas Gleixner <tglx@linutronix.de>
To: Vishal Parmar <vishistriker@gmail.com>, John Stultz <jstultz@google.com>
Cc: shuah@kernel.org, anna-maria@linutronix.de, frederic@kernel.org,
sboyd@kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] selftests: timers: improve adjtick output readability
Date: Thu, 31 Jul 2025 15:58:12 +0200 [thread overview]
Message-ID: <877bzoihsb.ffs@tglx> (raw)
In-Reply-To: <CAEOVoRwsHdAmn1d_SekD+ddWeUDJCooNsK_wDHxEyvtqkDXQZw@mail.gmail.com>
Vishal!
On Wed, Jul 30 2025 at 23:35, Vishal Parmar wrote:
Please do not top-post and trim your replies.
> The intent behind this change is to make output useful as is.
> for example, to provide a performance report in case of regression.
The point John was making:
>> So it might be worth looking into getting the output to be happy with
>> TAP while you're tweaking things here.
The kernel selftests are converting over to standardized TAP output
format, which is intended to aid automated testing.
So if we change the outpot format of this test, then we switch it over to
TAP format and do not invent yet another randomized output scheme.
> CSV format is also a good alternative if the maintainer prefers that.
The most important information is whether the test succeeded or not and
CSV format is not helping either to conform with the test output
standards.
For the success case, the actual numbers are uninteresting. In the
failure case it's sufficient to emit:
ksft_test_result_fail("Req: NNNN, Exp: $MMMM, Res: $LLLL\n", ...);
In case of regressions (fail), a report providing this output is good
enough for the relevant maintainer/developer to start investigating.
No?
Thanks,
tglx
next prev parent reply other threads:[~2025-07-31 13:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 16:03 [PATCH] selftests: timers: improve adjtick output readability Vishal Parmar
2025-07-29 0:33 ` John Stultz
[not found] ` <CAEOVoRwsHdAmn1d_SekD+ddWeUDJCooNsK_wDHxEyvtqkDXQZw@mail.gmail.com>
2025-07-31 13:58 ` Thomas Gleixner [this message]
2025-07-31 16:12 ` Vishal Parmar
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=877bzoihsb.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=shuah@kernel.org \
--cc=vishistriker@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.