3:07 p.m.
On Thu, Feb 14, 2019 at 9:26 AM Luis Chamberlain <mcgrof(a)kernel.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(a)ideasonboard.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