[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGS_qxoJtGYuFPuOBYfJd-gm0+dpHstMVJDQ7=9xdU8EtW9VFQ@mail.gmail.com>
Date: Fri, 8 Apr 2022 12:38:15 -0500
From: Daniel Latypov <dlatypov@...gle.com>
To: David Gow <davidgow@...gle.com>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
KUnit Development <kunit-dev@...glegroups.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] kunit: tool: cosmetic: don't specify duplicate kunit_shutdown's
On Thu, Apr 7, 2022 at 10:17 PM David Gow <davidgow@...gle.com> wrote:
>
> On Fri, Apr 8, 2022 at 3:39 AM Daniel Latypov <dlatypov@...gle.com> wrote:
> >
> > Context:
> > When using a non-UML arch, kunit.py will boot the test kernel with these
> > options by default:
> > > mem=1G console=tty kunit_shutdown=halt console=ttyS0 kunit_shutdown=reboot
> >
> > For QEMU, we need to use 'reboot', and for UML we need to use 'halt'.
> > If you switch them, kunit.py will hang until the --timeout expires.
> >
> > So the code currently unconditionally adds 'kunit_shutdown=halt' but
> > then appends 'reboot' when using QEMU (which overwrites it).
> >
> > This patch:
> > Having these duplicate options is a bit noisy.
> > Switch so we only add 'halt' for UML.
> >
> > I.e. we now get
> > UML: 'mem=1G console=tty console=ttyS0 kunit_shutdown=halt'
> > QEMU: 'mem=1G console=tty console=ttyS0 kunit_shutdown=reboot'
> >
> > Side effect: you can't overwrite kunit_shutdown on UML w/ --kernel_arg.
> > But you already couldn't for QEMU, and why would you want to?
> >
> > Signed-off-by: Daniel Latypov <dlatypov@...gle.com>
> > ---
>
> Thanks so much for fixing this: it had been quietly bugging me for a while.
>
> This looks pretty good as is, but I have a few suggestions for
> extending it which could be nice to have. I've put them inline below.
>
> Either way,
> Reviewed-by: David Gow <davidgow@...gle.com>
>
> > tools/testing/kunit/kunit_kernel.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
> > index 483f78e15ce9..9731ceb7ad92 100644
> > --- a/tools/testing/kunit/kunit_kernel.py
> > +++ b/tools/testing/kunit/kunit_kernel.py
> > @@ -158,7 +158,7 @@ class LinuxSourceTreeOperationsUml(LinuxSourceTreeOperations):
> > def start(self, params: List[str], build_dir: str) -> subprocess.Popen:
> > """Runs the Linux UML binary. Must be named 'linux'."""
> > linux_bin = os.path.join(build_dir, 'linux')
> > - return subprocess.Popen([linux_bin] + params,
> > + return subprocess.Popen([linux_bin] + params + ['kunit_shutdown=halt'],
>
> I'd slightly prefer it if we assigned these extra parameters to a
> separate variable, rather than including them directly in the
> subprocess.Popen call.
I'm not sure I understand the suggestion here.
But PTAL at the diff down below and see if that looks fine.
I'll send a v2 that moves all of the default kernel args into UML only
as they're UML-specific, as you pointed out.
>
> (One thing I'd like to do is to print out the command we're running,
> which we do for Qemu, and having it in a variable that's passed in
> would be convenient. I don't expect this patch to do that, but having
> these parameters separate would make that future diff a little
> smaller.)
>
> > stdin=subprocess.PIPE,
> > stdout=subprocess.PIPE,
> > stderr=subprocess.STDOUT,
> > @@ -332,7 +332,7 @@ class LinuxSourceTree(object):
> > def run_kernel(self, args=None, build_dir='', filter_glob='', timeout=None) -> Iterator[str]:
> > if not args:
> > args = []
> > - args.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt'])
> > + args.extend(['mem=1G', 'console=tty'])
>
> Does it make sense to also make these options UML only.
Yes, I think that's entirely correct.
mem=1G is redundant w/ the hard-coded '-m 1024' we pass to QEMU.
console=tty is overwritten by every architecture via its qemu_config.
So this patch would be better as
diff --git a/tools/testing/kunit/kunit_kernel.py
b/tools/testing/kunit/kunit_kernel.py
index 483f78e15ce9..d497adcd0684 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -158,6 +158,7 @@ class
LinuxSourceTreeOperationsUml(LinuxSourceTreeOperations):
def start(self, params: List[str], build_dir: str) -> subprocess.Popen:
"""Runs the Linux UML binary. Must be named 'linux'."""
linux_bin = os.path.join(build_dir, 'linux')
+ params.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt'])
return subprocess.Popen([linux_bin] + params,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
@@ -332,7 +333,6 @@ class LinuxSourceTree(object):
def run_kernel(self, args=None, build_dir='', filter_glob='',
timeout=None) -> Iterator[str]:
if not args:
args = []
- args.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt'])
if filter_glob:
args.append('kunit.filter_glob='+filter_glob)
>
> Under Qemu, the amount of memory is already passed separately to qemu,
> so adding another limit here seems counterproductive. If an
> architecture particularly needs it, we can add it to the
> per-architecture config.
>
On that note, sparc has a mem kernel_cmdline option.
tools/testing/kunit/qemu_configs/alpha.py: kernel_command_line='console=ttyS0',
tools/testing/kunit/qemu_configs/arm64.py:
kernel_command_line='console=ttyAMA0',
tools/testing/kunit/qemu_configs/arm.py: kernel_command_line='console=ttyAMA0',
tools/testing/kunit/qemu_configs/i386.py: kernel_command_line='console=ttyS0',
tools/testing/kunit/qemu_configs/powerpc.py:
kernel_command_line='console=ttyS0',
tools/testing/kunit/qemu_configs/riscv.py: kernel_command_line='console=ttyS0',
tools/testing/kunit/qemu_configs/s390.py: kernel_command_line='console=ttyS0',
tools/testing/kunit/qemu_configs/sparc.py:
kernel_command_line='console=ttyS0 mem=256M',
tools/testing/kunit/qemu_configs/x86_64.py: kernel_command_line='console=ttyS0',
Not sure why we'd do that atm.
Powered by blists - more mailing lists