From: "Paul E. McKenney" <paulmck@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] torture: Correctly fetch CPUs for kvm-build.sh with all native language
Date: Thu, 1 Apr 2021 15:33:29 -0700 [thread overview]
Message-ID: <20210401223329.GK2696@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20210401210802.GC116405@lothringen>
On Thu, Apr 01, 2021 at 11:08:02PM +0200, Frederic Weisbecker wrote:
> On Thu, Apr 01, 2021 at 02:02:53PM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 01, 2021 at 10:41:13PM +0200, Frederic Weisbecker wrote:
> > > On Thu, Apr 01, 2021 at 01:40:22PM -0700, Paul E. McKenney wrote:
> > > > On Thu, Apr 01, 2021 at 10:31:12PM +0200, Frederic Weisbecker wrote:
> > > > > On Thu, Apr 01, 2021 at 11:51:16AM -0700, Paul E. McKenney wrote:
> > > > > > On Thu, Apr 01, 2021 at 03:26:02PM +0200, Frederic Weisbecker wrote:
> > > > > > > Grepping for "CPU" on lscpu output isn't always successful, depending
> > > > > > > on the local language setting. As a result, the build can be aborted
> > > > > > > early with:
> > > > > > >
> > > > > > > "make: the '-j' option requires a positive integer argument"
> > > > > > >
> > > > > > > Prefer a more generic solution.
> > > > > > >
> > > > > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > > > >
> > > > > > Good catch, applied, thank you!
> > > > > >
> > > > > > There is a similar construct in kvm-remote.sh, so I added a similar
> > > > > > fix to your patch.
> > > > > >
> > > > > > But what about this in functions.sh?
> > > > > >
> > > > > > nt="`lscpu | grep '^NUMA node0' | sed -e 's/^[^,]*,\([0-9]*\),.*$/\1/'`"
> > > > > >
> > > > > > I am guessing that "node0" is human-language-independent, but is "NUMA"?
> > > > >
> > > > > I thought they wouldn't bother translating that, but they did...
> > > > >
> > > > > NUMA node0 CPU(s): 0-7
> > > > >
> > > > > becomes:
> > > > >
> > > > > Nœud NUMA 0 de processeur(s) : 0-7
> > > > >
> > > > > Not sure about the best way to fix it.
> > > >
> > > > The rude and crude fix is for the scripts to force the local language
> > > > to English. ;-)
> > >
> > > I don't have a better answer :o)
> >
> > If you set the environment variable LANG to en_US.UTF-8, does that
> > make things work for you? Huh. Setting it to fr_FR.UTF-8 does not
> > shift lscpu out of English for me, so I am guessing "no".
>
> Maybe that language isn't installed in your system. I would expect
> en_US.UTF-8 to be supported pretty much everywhere though. At least it
> works for me with: "LANG=en_US.UTF-8 lscpu".
>
> Thanks.
How about like this? I put this only in kvm.sh for the moment, but
if these keep cropping up I will just hit all the scripts. ;-)
Thanx, Paul
------------------------------------------------------------------------
commit 4ca332016ed81c15ebb3b744dbfc462281c544b8
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Thu Apr 1 15:26:56 2021 -0700
torture: Set kvm.sh language to English
Some of the code invoked directly and indirectly from kvm.sh parses
the output of commands. This parsing assumes English, which can cause
failures if the user has set some other language. In a few cases,
there are language-independent commands available, but this is not
always the case. Therefore, as an alternative to polyglot parsing,
this commit sets the LANG environment variable to en_US.UTF-8.
Reported-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh b/tools/testing/selftests/rcutorture/bin/kvm.sh
index fab3bd9..390bb97 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -20,6 +20,9 @@ mkdir $T
cd `dirname $scriptname`/../../../../../
+# This script knows only English.
+LANG=en_US.UTF-8; export LANG
+
dur=$((30*60))
dryrun=""
KVM="`pwd`/tools/testing/selftests/rcutorture"; export KVM
next prev parent reply other threads:[~2021-04-01 22:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 13:26 Frederic Weisbecker
2021-04-01 18:51 ` Paul E. McKenney
2021-04-01 20:31 ` Frederic Weisbecker
2021-04-01 20:40 ` Paul E. McKenney
2021-04-01 20:41 ` Frederic Weisbecker
2021-04-01 21:02 ` Paul E. McKenney
2021-04-01 21:08 ` Frederic Weisbecker
2021-04-01 22:33 ` Paul E. McKenney [this message]
2021-04-01 22:48 ` Frederic Weisbecker
2021-04-05 14:23 ` Christian Kujau
2021-04-05 15:25 ` Paul E. McKenney
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=20210401223329.GK2696@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®