[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFd5g46BG=-sjA+ZFz_F-2wEGrD_mhU-W+kHsr1rGsKEv2YtJw@mail.gmail.com>
Date: Thu, 14 Feb 2019 14:07:18 -0800
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Kieran Bingham <kieran.bingham@...asonboard.com>,
Greg KH <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...gle.com>, shuah@...nel.org,
Joel Stanley <joel@....id.au>,
Michael Ellerman <mpe@...erman.id.au>,
Joe Perches <joe@...ches.com>, brakmo@...com,
Steven Rostedt <rostedt@...dmis.org>,
"Bird, Timothy" <Tim.Bird@...y.com>,
Kevin Hilman <khilman@...libre.com>,
Julia Lawall <julia.lawall@...6.fr>,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jeff Dike <jdike@...toit.com>,
Richard Weinberger <richard@....at>,
linux-um@...ts.infradead.org, Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Rob Herring <robh@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
Frank Rowand <frowand.list@...il.com>,
Knut Omang <knut.omang@...cle.com>,
Felix Guo <felixguoxiuping@...il.com>
Subject: Re: [RFC v3 14/19] Documentation: kunit: add documentation for KUnit
On Thu, Feb 14, 2019 at 9:26 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> On Wed, Feb 13, 2019 at 04:17:13PM -0800, Brendan Higgins wrote:
> > On Wed, Feb 13, 2019 at 1:55 PM Kieran Bingham
> > <kieran.bingham@...asonboard.com> wrote:
> > Oh, yep, you are right. Does that mean we should bother at all with a defconfig?
>
> If one wanted a qemu enabled type of kernel and also for kuniut one
> could imply run:
>
> make kvmconfig
> make kunitconfig
>
> That would get what you suggest above of default "bells and whistles"
> and keep the kuniut as a fragment.
>
> Hm, actually the kvmconfig doesn't really enable the required fragments
> for qemu, so perhaps one would be good. It would have the serial stuff
> for instance.
>
> > Luis, I know you said you wanted one. I am thinking just stick with
> > the UML one? The downside there is we then get stuck having to
> > maintain the fragment and the defconfig. I right now (in the new
> > revision I am working on) have the Python kunit_tool copy the
> > defconfig if no kunitconfig is provided and a flag is set. It would be
> > pretty straightforward to make it merge in the fragment instead.
>
> Up to you in the end.
I don't really have any opinions on the matter; I don't really use
defconfigs in any of my workflows. So, I just want whatever is easier
for people. The thing that makes the most sense to me would be to
provide a "merge-kunitconfig" option similar to what kselftest does,
but I don't intend on doing that in the initial patchset, unless
someone really thinks that I should do it. So in the meantime, I guess
provide both since that gives people options?
In anycase, I just (finally) sent out v4, so I suggest we continue the
discussion over there.
Cheers
Powered by blists - more mailing lists