linux-kernel - Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Dec 2018 15:09:26 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Kieran Bingham <kieran.bingham@...asonboard.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Kent Overstreet <kent.overstreet@...il.com>,
        Eryu Guan <guaneryu@...il.com>,
        Eric Sandeen <sandeen@...deen.net>, jeffm@...e.com,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...gle.com>, shuah@...nel.org,
        Joel Stanley <joel@....id.au>, mpe@...erman.id.au,
        joe@...ches.com, brakmo@...com, rostedt@...dmis.org,
        Tim.Bird@...y.com, khilman@...libre.com,
        Julia Lawall <julia.lawall@...6.fr>,
        linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        jdike@...toit.com, richard@....at, linux-um@...ts.infradead.org,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, Rob Herring <robh@...nel.org>,
        dan.j.williams@...el.com, linux-nvdimm@...ts.01.org,
        Frank Rowand <frowand.list@...il.com>,
        Knut Omang <knut.omang@...cle.com>,
        Felix Guo <felixguoxiuping@...il.com>,
        linux-fsdevel@...r.kernel.org
Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit
 config and kernel

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
> > >> <kieran.bingham@...asonboard.com> 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