From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brendan Higgins Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Date: Mon, 3 Dec 2018 15:48:15 -0800 Message-ID: References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <841cf4ae-501b-05ae-5863-a51010709b67-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org Cc: brakmo-b10kYP2dOMg@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Rob Herring , Frank Rowand , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, richard-/L3Ra7n9ekc@public.gmane.org, Knut Omang , Felix Guo , Joel Stanley , jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org, Tim.Bird-7U/KSKJipcs@public.gmane.org, Kees Cook , linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org, Julia Lawall , kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Greg KH , Linux Kernel Mailing List , mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Daniel Vetter , mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org, joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org, khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org List-Id: linux-nvdimm@lists.01.org On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham wrote: > > Hi Brendan, > > Thanks again for this series! > > On 28/11/2018 19:36, Brendan Higgins wrote: > > The ultimate goal is to create minimal isolated test binaries; in the > > meantime we are using UML to provide the infrastructure to run tests, so > > define an abstract way to configure and run tests that allow us to > > change the context in which tests are built without affecting the user. > > This also makes pretty and dynamic error reporting, and a lot of other > > nice features easier. > > > I wonder if we could somehow generate a shared library object > 'libkernel' or 'libumlinux' from a UM configured set of headers and > objects so that we could create binary targets directly ? That's an interesting idea. I think it would be difficult to figure out exactly where to draw the line of what goes in there and what needs to be built specific to a test a priori. Of course, that leads into the biggest problem in general, needed to know what I need to build to test the thing that I want to test. Nevertheless, I could definitely imagine that being useful in a lot of cases. > > diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py > > new file mode 100644 > > index 0000000000000..bba7ea7ca1869 > > --- /dev/null > > +++ b/tools/testing/kunit/kunit_kernel.py ... > > + def make(self, jobs): > > + try: > > + subprocess.check_output([ > > + 'make', > > + 'ARCH=um', > > + '--jobs=' + str(jobs)]) > > Perhaps as a future extension: > > It would be nice if we could set an O= here to keep the source tree > pristine. > > In fact I might even suggest that this should always be set so that the > unittesting could live along side an existing kernel build? : > > O ?= $KBUILD_SRC/ > O := $(O)/kunittest/$(ARCH)/build I agree with that. It would be pretty annoying to run a unit test and have it mess up your .config and force you to rebuild everything else. (I have actually done this to myself a couple of times...) Cheers