From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 848F621184AB6 for ; Thu, 6 Dec 2018 17:05:22 -0800 (PST) Received: by mail-pf1-f193.google.com with SMTP id h3so1055095pfg.1 for ; Thu, 06 Dec 2018 17:05:22 -0800 (PST) Date: Thu, 6 Dec 2018 17:05:17 -0800 From: Luis Chamberlain Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel 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-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Kieran Bingham Cc: brakmo@fb.com, Knut Omang , jeffm@suse.com, Brendan Higgins , dri-devel@lists.freedesktop.org, Sasha Levin , linux-kselftest@vger.kernel.org, shuah@kernel.org, Rob Herring , Frank Rowand , linux-nvdimm@lists.01.org, mpe@ellerman.id.au, Eric Sandeen , Matthew Wilcox , Felix Guo , Joel Stanley , Tim.Bird@sony.com, Petr Mladek , jdike@addtoit.com, linux-um@lists.infradead.org, rostedt@goodmis.org, Julia Lawall , kunit-dev@googlegroups.com, richard@nod.at, fsdevel@vger.kernel.org, Greg KH , Linux Kernel Mailing List , Kent Overstreet , Eryu Guan , Daniel Vetter , Kees Cook , joe@perches.com, khilman@baylibre.com List-ID: 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 _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm