From mboxrd@z Thu Jan 1 00:00:00 1970 From: pmladek@suse.com (Petr Mladek) Date: Tue, 11 Dec 2018 15:09:26 +0100 Subject: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel In-Reply-To: <20181206153718.GD24603@bombadil.infradead.org> 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> Message-ID: <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz> Content-Type: text/plain; charset="UTF-8" Message-ID: <20181211140926.hJoSiW2NXIUd5l0sZGT_29n5BQVj7Ep4UNrF09AtMDU@z> On Thu 2018-12-06 07:37:18, Matthew Wilcox wrote: > On Thu, Dec 06, 2018@12:32:47PM +0000, Kieran Bingham wrote: > > On 04/12/2018 20:47, Luis Chamberlain wrote: > > > On Mon, Dec 03, 2018@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