From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis Chamberlain Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Date: Thu, 6 Dec 2018 17:05:17 -0800 Message-ID: <20181207010517.GH28501@garbanzo.do-not-panic.com> References: <20181128193636.254378-1-brendanhiggins@google.com> <20181128193636.254378-12-brendanhiggins@google.com> <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com> <20181204204701.GT28501@garbanzo.do-not-panic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: 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 Cc: brakmo-b10kYP2dOMg@public.gmane.org, Knut Omang , jeffm-IBi9RG/b67k@public.gmane.org, Brendan Higgins , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Sasha Levin , linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Rob Herring , Frank Rowand , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org, Eric Sandeen , Matthew Wilcox , Felix Guo , Joel Stanley , Tim.Bird-7U/KSKJipcs@public.gmane.org, Petr Mladek , jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org, linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org, Julia Lawall , kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, richard-/L3Ra7n9ekc@public.gmane.org, fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Greg KH , Linux Kernel Mailing List , Kent Overstreet Eryu Guan List-Id: dri-devel@lists.freedesktop.org On Thu, Dec 06, 2018 at 12:32:47PM +0000, Kieran Bingham wrote: > My main initial idea for a libumlinux is to provide infrastructure such > as our linked-lists and other kernel formatting so that we can take > kernel code directly to userspace for test and debug (assuming that > there are no hardware dependencies or things that we can't mock out) The tools/ directory already does this for a tons of things. Its where I ended up placing some API I tested a long time ago when I wanted to test it in userspace, and provide the unit test in userspace (for my linker table patches). > Now we just have to start the race to see who can tweak the kernel build > system to produce an output library first :) Should be relatively easy if the tools directory used. Yes, there is an inherent risk of duplication, but that was decided long ago. Luis