From: Bagas Sanjaya <bagasdotme@gmail.com>
To: "Hanne-Lotta Mäenpää" <hannelotta@gmail.com>,
"Shuah Khan" <skhan@linuxfoundation.org>,
shuah@kernel.org, alexandre.belloni@bootlin.com
Cc: linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH v2] selftests: Improve test output grammar, code style
Date: Mon, 26 May 2025 09:52:56 +0700 [thread overview]
Message-ID: <aDPXiE4z1_fejuy3@archie.me> (raw)
In-Reply-To: <ff076589-4a93-4e4c-8e85-77499e27898c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]
On Sun, May 25, 2025 at 09:27:31PM +0300, Hanne-Lotta Mäenpää wrote:
> Hello,
>
> On 5/23/25 01:14, Shuah Khan wrote:
> > On 5/16/25 02:42, Hanne-Lotta Mäenpää wrote:
> > > Add small grammar fixes in perf events and Real Time Clock tests'
> > > output messages.
> > >
> > > Include braces around a single if statement, when there are multiple
> > > statements in the else branch, to align with the kernel coding style.
> >
> > This patch combines several changes in one including combining changes
> > to two tests.
> >
> > >
> > > Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>
> > > ---
> > >
> > > Notes:
> > > v1 -> v2: Improved wording in RTC tests based on feedback from
> > > Alexandre Belloni <alexandre.belloni@bootlin.com>
> > >
> > > tools/testing/selftests/perf_events/watermark_signal.c | 7 ++++---
> > > tools/testing/selftests/rtc/rtctest.c | 10 +++++-----
> > > 2 files changed, 9 insertions(+), 8 deletions(-)
> > >
> >
> > Send separate patches for selftests/perf_events and selftests/rtc/rtctest.c
>
> Sure, I can do that. If I split this patch into two, is it OK to send the
> other patch as a new one (without version history)? Or should I send both
> patches converted to a patch series (v3)?
Send both patches as a series.
> >
> > > goto cleanup;
> > > }
> > > diff --git a/tools/testing/selftests/rtc/rtctest.c b/tools/testing/
> > > selftests/rtc/rtctest.c
> > > index be175c0e6ae3..930bf0ce4fa6 100644
> > > --- a/tools/testing/selftests/rtc/rtctest.c
> > > +++ b/tools/testing/selftests/rtc/rtctest.c
> > > @@ -138,10 +138,10 @@ TEST_F_TIMEOUT(rtc, date_read_loop,
> > > READ_LOOP_DURATION_SEC + 2) {
> > > rtc_read = rtc_time_to_timestamp(&rtc_tm);
> > > /* Time should not go backwards */
> > > ASSERT_LE(prev_rtc_read, rtc_read);
> > > - /* Time should not increase more then 1s at a time */
> > > + /* Time should not increase more than 1s per read */
> > > ASSERT_GE(prev_rtc_read + 1, rtc_read);
> > > - /* Sleep 11ms to avoid killing / overheating the RTC */
> > > + /* Sleep 11ms to avoid overheating the RTC */
> >
> > This change removes important information. What is the reason for this
> > change?
>
> Well, it is less verbose and still informative (avoiding overheating). I can
> leave out this change, though.
s/then/than/ typofix should be kept.
>
> >
> > > nanosleep_with_retries(READ_LOOP_SLEEP_MS * 1000000);
> > > prev_rtc_read = rtc_read;
> > > @@ -236,7 +236,7 @@ TEST_F(rtc, alarm_alm_set) {
> > > if (alarm_state == RTC_ALARM_DISABLED)
> > > SKIP(return, "Skipping test since alarms are not supported.");
> > > if (alarm_state == RTC_ALARM_RES_MINUTE)
> > > - SKIP(return, "Skipping test since alarms has only minute
> > > granularity.");
> > > + SKIP(return, "Skipping test since alarm has only minute
> > > granularity.");
> > > rc = ioctl(self->fd, RTC_RD_TIME, &tm);
> > > ASSERT_NE(-1, rc);
> > > @@ -306,7 +306,7 @@ TEST_F(rtc, alarm_wkalm_set) {
> > > if (alarm_state == RTC_ALARM_DISABLED)
> > > SKIP(return, "Skipping test since alarms are not supported.");
> >
> > This one still says "alarms"
>
> Yes, because "alarms are not supported" refers to alarms as a feature.
Disambiguate (like "alarms feature is not supported")?
>
> >
> > > if (alarm_state == RTC_ALARM_RES_MINUTE)
> > > - SKIP(return, "Skipping test since alarms has only minute
> > > granularity.");
> > > + SKIP(return, "Skipping test since alarm has only minute
> > > granularity.");
> >
> > Isn't "alarms" consistent with other messages?
>
> Yes, plural "alarms" would be consistent with other messages, and when
> referring to them as a feature. The verb form should then change, either:
>
> - alarm has ... OR
> - alarms have ...
>
> In the test, only one alarm is set - it makes sense to refer to it as
> singular. I received feedback regarding this from Alexandre, because I had
> plural form in the first version of this patch.
I would rather write the message as "Skipping test since the alarm has ..."
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2025-05-26 2:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 8:42 [PATCH v2] selftests: Improve test output grammar, code style Hanne-Lotta Mäenpää
2025-05-22 22:14 ` Shuah Khan
2025-05-25 18:27 ` Hanne-Lotta Mäenpää
2025-05-26 2:52 ` Bagas Sanjaya [this message]
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=aDPXiE4z1_fejuy3@archie.me \
--to=bagasdotme@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=hannelotta@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.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;
as well as URLs for NNTP newsgroup(s).