On 12/11/18 2:41 PM, Steven Rostedt wrote:
On Tue, 11 Dec 2018 15:09:26 +0100 Petr Mladek pmladek@suse.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.