Linux-Trace-Devel Archive on lore.kernel.org
 help / Atom feed
* Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
       [not found]             ` <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz>
@ 2018-12-11 14:41               ` Steven Rostedt
  2018-12-11 17:01                 ` Anton Ivanov
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Rostedt @ 2018-12-11 14:41 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Matthew Wilcox, Kieran Bingham, Luis Chamberlain,
	Brendan Higgins, Kent Overstreet, Eryu Guan, Eric Sandeen, jeffm,
	Sasha Levin, Greg KH, Kees Cook, shuah, Joel Stanley, mpe, joe,
	brakmo, Tim.Bird, khilman, Julia Lawall, linux-kselftest,
	kunit-dev, Linux Kernel Mailing List, jdike, richard, linux-um,
	Daniel Vetter, dri-devel, Rob Herring, dan.j.williams,
	linux-nvdimm, Frank Rowand, Knut Omang, Felix Guo, linux-fsdevel,
	Linux Trace Devel

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.

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
  2018-12-11 14:41               ` [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Steven Rostedt
@ 2018-12-11 17:01                 ` Anton Ivanov
  2019-02-09  0:40                   ` Brendan Higgins
  0 siblings, 1 reply; 3+ messages in thread
From: Anton Ivanov @ 2018-12-11 17:01 UTC (permalink / raw)
  To: Steven Rostedt, Petr Mladek
  Cc: brakmo, Knut Omang, jeffm, Brendan Higgins, dri-devel,
	Sasha Levin, Linux Trace Devel, linux-kselftest, shuah,
	Rob Herring, Frank Rowand, linux-nvdimm, mpe, Eric Sandeen,
	Kieran Bingham, Matthew Wilcox, Felix Guo, Joel Stanley,
	Kent Overstreet, jdike, Tim.Bird, linux-um, Julia Lawall,
	dan.j.williams, kunit-dev, richard, Greg KH,
	Linux Kernel Mailing List, Luis Chamberlain, Eryu Guan,
	Daniel Vetter, Kees Cook, joe, linux-fsdevel, khilman


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.

-- 

Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
  2018-12-11 17:01                 ` Anton Ivanov
@ 2019-02-09  0:40                   ` Brendan Higgins
  0 siblings, 0 replies; 3+ messages in thread
From: Brendan Higgins @ 2019-02-09  0:40 UTC (permalink / raw)
  To: Anton Ivanov
  Cc: Steven Rostedt, Petr Mladek, brakmo, Knut Omang, jeffm,
	dri-devel, Sasha Levin, Linux Trace Devel, linux-kselftest,
	shuah, Rob Herring, Frank Rowand, linux-nvdimm, mpe,
	Eric Sandeen, Kieran Bingham, Matthew Wilcox, Felix Guo,
	Joel Stanley, Kent Overstreet, jdike, Tim.Bird, linux-um,
	Julia Lawall, dan.j.williams, kunit-dev, richard, Greg KH,
	Linux Kernel Mailing List, Luis Chamberlain, Eryu Guan,
	Daniel Vetter, Kees Cook, joe, linux-fsdevel, khilman

On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov
<anton.ivanov@cambridgegreys.com> wrote:
>
>
> 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.

Whoops, sorry, didn't see your comment before I went on vacation.

I completely agree. It is also annoying when trying to test other
really low level parts of the kernel. I would really like to get KUnit
to the point where it does not have any dependencies on anything in
the kernel, but that is very challenging for many reasons. This
loosely relates to what Luis, myself, and others have talked about in
other threads about having a stricter notion of code dependencies in
the kernel. Thinking about it now, I suspect it might be easier to
limit KUnit's dependency on kernel infrastructure first; that could
kind of motivate the later work.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20181128193636.254378-1-brendanhiggins@google.com>
     [not found] ` <20181128193636.254378-12-brendanhiggins@google.com>
     [not found]   ` <841cf4ae-501b-05ae-5863-a51010709b67@ideasonboard.com>
     [not found]     ` <CAFd5g47x-UNja72k-CWPmWz9+LTn8pF8Wj5Poq+2FJ93E=vymA@mail.gmail.com>
     [not found]       ` <20181204204701.GT28501@garbanzo.do-not-panic.com>
     [not found]         ` <f8722f4a-44c8-24c2-c433-5178f9f40b82@ideasonboard.com>
     [not found]           ` <20181206153718.GD24603@bombadil.infradead.org>
     [not found]             ` <20181211140926.7wzd5jh6klcfsfgz@pathway.suse.cz>
2018-12-11 14:41               ` [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel Steven Rostedt
2018-12-11 17:01                 ` Anton Ivanov
2019-02-09  0:40                   ` Brendan Higgins

Linux-Trace-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-trace-devel/0 linux-trace-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-trace-devel linux-trace-devel/ https://lore.kernel.org/linux-trace-devel \
		linux-trace-devel@vger.kernel.org linux-trace-devel@archiver.kernel.org
	public-inbox-index linux-trace-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-trace-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox