[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34f9e9f3-6bca-f11f-097c-c6e0cb779b61@cambridgegreys.com>
Date: Tue, 11 Dec 2018 17:01:48 +0000
From: Anton Ivanov <anton.ivanov@...bridgegreys.com>
To: Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>
Cc: brakmo@...com, Knut Omang <knut.omang@...cle.com>, jeffm@...e.com,
Brendan Higgins <brendanhiggins@...gle.com>,
dri-devel@...ts.freedesktop.org,
Sasha Levin <Alexander.Levin@...rosoft.com>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
linux-kselftest@...r.kernel.org, shuah@...nel.org,
Rob Herring <robh@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
linux-nvdimm@...ts.01.org, mpe@...erman.id.au,
Eric Sandeen <sandeen@...deen.net>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Matthew Wilcox <willy@...radead.org>,
Felix Guo <felixguoxiuping@...il.com>,
Joel Stanley <joel@....id.au>,
Kent Overstreet <kent.overstreet@...il.com>, jdike@...toit.com,
Tim.Bird@...y.com, linux-um@...ts.infradead.org,
Julia Lawall <julia.lawall@...6.fr>, dan.j.williams@...el.com,
kunit-dev@...glegroups.com, richard@....at,
Greg KH <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Eryu Guan <guaneryu@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Kees Cook <keescook@...gle.com>, joe@...ches.com,
linux-fsdevel@...r.kernel.org, khilman@...libre.com
Subject: Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit
config and kernel
On 12/11/18 2:41 PM, Steven Rostedt wrote:
> On Tue, 11 Dec 2018 15:09:26 +0100
> Petr Mladek <pmladek@...e.com> wrote:
>
>>> 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.
> No, please do not change the %pX 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").
> trace-cmd and perf know about most of the %pX data and how to read it.
> Perhaps we can extend the libtraceevent library to export a generic way
> to read data from printk() output for other tools to use.
Going back for a second to using UML for this. UML console at present is
interrupt driven - it emulates serial IO using several different
back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on
the host side are used to trigger the UML interrupts - both read and write.
This works OK for normal use, but may result in all kinds of interesting
false positives/false negatives when UML is used to run unit tests
against a change which changes interrupt behavior.
IMO it may be useful to consider some alternatives specifically for unit
test coverage purposes where printk and/or the whole console output
altogether bypass some of the IRQ driven semantics.
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
Powered by blists - more mailing lists