From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3B87C07E85 for ; Tue, 11 Dec 2018 14:09:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B23672084C for ; Tue, 11 Dec 2018 14:09:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B23672084C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726839AbeLKOJc (ORCPT ); Tue, 11 Dec 2018 09:09:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:41640 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726444AbeLKOJb (ORCPT ); Tue, 11 Dec 2018 09:09:31 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2D834B036; Tue, 11 Dec 2018 14:09:28 +0000 (UTC) Date: Tue, 11 Dec 2018 15:09:26 +0100 From: Petr Mladek To: Matthew Wilcox Cc: Kieran Bingham , Luis Chamberlain , Brendan Higgins , Kent Overstreet , Eryu Guan , Eric Sandeen , jeffm@suse.com, Sasha Levin , Greg KH , Kees Cook , shuah@kernel.org, Joel Stanley , mpe@ellerman.id.au, joe@perches.com, brakmo@fb.com, rostedt@goodmis.org, Tim.Bird@sony.com, khilman@baylibre.com, Julia Lawall , linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, Linux Kernel Mailing List , jdike@addtoit.com, richard@nod.at, linux-um@lists.infradead.org, Daniel Vetter , dri-devel@lists.freedesktop.org, Rob Herring , dan.j.williams@intel.com, linux-nvdimm@lists.01.org, Frank Rowand , Knut Omang , Felix Guo , linux-fsdevel@vger.kernel.org Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Message-ID: <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> 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> <20181206153718.GD24603@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181206153718.GD24603@bombadil.infradead.org> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2018-12-06 07:37:18, Matthew Wilcox wrote: > On Thu, Dec 06, 2018 at 12:32:47PM +0000, Kieran Bingham wrote: > > On 04/12/2018 20:47, Luis Chamberlain wrote: > > > On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote: > > >> On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham > > >> wrote: > > > Developers working upstream do modify their kernels a lot, so we'd have > > > to update such libraries quite a bit, but I think that's fine too. The > > > *real* value I think from the above suggestion would be enterprise / > > > mobile distros or stable kernel maintainers which have a static kernel > > > they need to support for a relatively *long time*, consider a 10 year > > > time frame. Running unit tests without qemu with uml and libraries for > > > respective kernels seems real worthy. > > > > I think any such library might be something generated by the kernel > > build system, so if someone makes substantial changes to a core > > component provided by the library - it can be up to them to build a > > corresponding userspace library as well. > > > > 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) > > We have liburcu already, which is good. The main sticking points are: > > - printk has started adding a lot of %pX enhancements which printf > obviously doesn't know about. I wonder how big problem it is and if it is worth using another approach. An alternative would be to replace them with helper functions the would produce the same string. The meaning would be easier to understand. But concatenating with the surrounding text would be less elegant. People might start using pr_cont() that is problematic (mixed lines). Also the %pX formats are mostly used to print context of some structures. Even the helper functions would need some maintenance to keep them compatible. BTW: The printk() feature has been introduced 10 years ago by the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure support for extended '%p' specifiers"). Best Regards, Petr