From mboxrd@z Thu Jan 1 00:00:00 1970 From: mcgrof at kernel.org (Luis Chamberlain) Date: Thu, 14 Feb 2019 09:26:39 -0800 Subject: [RFC v3 14/19] Documentation: kunit: add documentation for KUnit In-Reply-To: References: <20181128193636.254378-15-brendanhiggins@google.com> <20181130034525.GP18410@garbanzo.do-not-panic.com> <0927c42a-8e65-f410-e6ed-27576572577f@ideasonboard.com> <57c3dc86-236f-e981-249a-8bbfe5c19f0e@ideasonboard.com> Message-ID: <20190214172639.GD11489@garbanzo.do-not-panic.com> On Wed, Feb 13, 2019 at 04:17:13PM -0800, Brendan Higgins wrote: > On Wed, Feb 13, 2019 at 1:55 PM Kieran Bingham > 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. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: mcgrof@kernel.org (Luis Chamberlain) Date: Thu, 14 Feb 2019 09:26:39 -0800 Subject: [RFC v3 14/19] Documentation: kunit: add documentation for KUnit In-Reply-To: References: <20181128193636.254378-15-brendanhiggins@google.com> <20181130034525.GP18410@garbanzo.do-not-panic.com> <0927c42a-8e65-f410-e6ed-27576572577f@ideasonboard.com> <57c3dc86-236f-e981-249a-8bbfe5c19f0e@ideasonboard.com> Message-ID: <20190214172639.GD11489@garbanzo.do-not-panic.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190214172639.EV_JTuMnBYDOUE7h0Op7eIGpYz70R180PlWt2zjTwzk@z> On Wed, Feb 13, 2019@04:17:13PM -0800, Brendan Higgins wrote: > On Wed, Feb 13, 2019 at 1:55 PM Kieran Bingham > 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. Luis