All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Higgins <brendanhiggins@google.com>
To: Daniel Latypov <dlatypov@google.com>
Cc: David Gow <davidgow@google.com>,
	Kees Cook <keescook@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	KUnit Development <kunit-dev@googlegroups.com>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	maxime@cerno.tech
Subject: Re: [PATCH] Documentation: kunit: update kconfig options needed for UML coverage
Date: Mon, 28 Mar 2022 12:54:30 -0400	[thread overview]
Message-ID: <CAFd5g45f3X3xF2vz2BkTHRqOC4uW6GZxtUUMaP5mwwbK8uNVtA@mail.gmail.com> (raw)
In-Reply-To: <CAGS_qxq_vFtGS4BGieZz8L3QH7rZ7ZN25pGYmjWWoXbTGOKC9A@mail.gmail.com>

On Mon, Mar 28, 2022 at 12:35 PM Daniel Latypov <dlatypov@google.com> wrote:
>
> On Fri, Mar 25, 2022 at 9:56 PM David Gow <davidgow@google.com> wrote:
> >
>
> <snip>
>
> > >         # Append coverage options to the current config
> > > -       $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
> > > +       $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
> > >         $ ./tools/testing/kunit/kunit.py run
> >
> > Would we want to instead use a chain of --kconfig_add arguments? (I
> > think there are advantages either way...)
>
> I've been considering this ever since the --kconfig_add patch was accepted.
> It's more compatible w/ commands using --kunitconfig, but it also
> looks very verbose.
> E.g. it looks like
>
> $ tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6
> --kconfig_add=CONFIG_DEBUG_INFO=y
> --kconfig_add=CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
> --kconfig_add=CONFIG_GCOV=y

I don't think it's *that* much more verbose, but I see your point. I
personally prefer this, but not enough to argue about it.

> Neither looks very appealing to me, so I've just kept it as-is for now.
>
> Maybe there's something we can do to make this easier (e.g. allowing
> --kunitconfig to be repeated and mergable)?

I would like --kunitconfig to be repeadable and mergable.

  reply	other threads:[~2022-03-28 16:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-26  0:33 [PATCH] Documentation: kunit: update kconfig options needed for UML coverage Daniel Latypov
2022-03-26  2:56 ` David Gow
2022-03-28 16:35   ` Daniel Latypov
2022-03-28 16:54     ` Brendan Higgins [this message]
2022-03-28 18:58       ` Daniel Latypov
2022-03-28 19:36         ` Brendan Higgins
2022-03-28  7:58 ` Maxime Ripard
2022-03-28 16:27 ` Brendan Higgins

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=CAFd5g45f3X3xF2vz2BkTHRqOC4uW6GZxtUUMaP5mwwbK8uNVtA@mail.gmail.com \
    --to=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=dlatypov@google.com \
    --cc=keescook@chromium.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --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 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.