Re: [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree

[Masami Hiramatsu]

Hi Frank,

Thank you for your comment!

On Sun, 23 Jun 2019 12:58:45 -0700
Frank Rowand <frowand.list@xxxxxxxxx> wrote:

> Hi Masami,
> 
> On 6/21/19 9:18 AM, Masami Hiramatsu wrote:
> > Hi,
> > 
> > Here is an RFC series of patches to add boot-time tracing using
> > devicetree.
> > 
> > Currently, kernel support boot-time tracing using kernel command-line
> > parameters. But that is very limited because of limited expressions
> > and limited length of command line. Recently, useful features like
> > histogram, synthetic events, etc. are being added to ftrace, but it is
> > clear that we can not expand command-line options to support these
> > features.
> 
> "it is clear that we can not expand command-line options" needs a fuller
> explanation.  And maybe further exploration.

Indeed. As an example of tracing settings in the first mail, even for simple
use-case,  the trace command is long and complicated. I think it is hard to
express that as 1-liner kernel command line. But devicetree looks very good
for expressing structured data. That is great and I like it :)

> > 
> > Hoever, I've found that there is a devicetree which can pass more
> > structured commands to kernel at boot time :) The devicetree is usually
> > used for dscribing hardware configuration, but I think we can expand it
> 
> Devicetree is standardized and documented as hardware description.

Yes, at this moment. Can't we talk about some future things?

> > for software configuration too (e.g. AOSP and OPTEE already introduced
> > firmware node.) Also, grub and qemu already supports loading devicetree,
> > so we can use it not only on embedded devices but also on x86 PC too.
> 
> Devicetree is NOT for configuration information.  This has been discussed
> over and over again in mail lists, at various conferences, and was also an
> entire session at plumbers a few years ago:
> 
>    https://elinux.org/Device_tree_future#Linux_Plumbers_2016_Device_Tree_Track

Thanks, I'll check that.

> 
> There is one part of device tree that does allow non-hardware description,
> which is the "chosen" node which is provided to allow communication between
> the bootloader and the kernel.

Ah, "chosen" will be suit for me :)

> There clearly are many use cases for providing configuration information
> and other types of data to a booting kernel.  I have been encouraging
> people to come up with an additional boot time communication channel or
> data object to support this use case.  So far, no serious proposal that
> I am aware of.

Hmm, then, can we add "ftrace" node under "chosen" node?
It seems that "chosen" is supporting some (flat) properties, and I would
like to add a tree of nodes for describing per-event setting.

What about something like below? (do we need "compatible" ?)

chosen {
	linux,ftrace {
		tp-printk;
		buffer-size-kb = <400>;
		event0 {
			event = "...";
		};
	};
};

[..]
> > 
> > I would like to discuss on some points about this idea.
> > 
> > - Can we use devicetree for configuring kernel dynamically?
> 
> No.  Sorry.
> 
> My understanding of this proposal is that it is intended to better
> support boot time kernel and driver debugging.  As an alternate
> implementation, could you compile the ftrace configuration information
> directly into a kernel data structure?  It seems like it would not be
> very difficult to populate the data structure data via a few macros.

No, that is not what I intended. My intention was to trace boot up
process "without recompiling kernel", but with a structured data.

For such purpose, we have to implement a tool to parse and pack the
data and a channel to load it at earlier stage in bootloader. And
those are already done by devicetree. Thus I thought I could get a
piggyback on devicetree.

Thank you,

-- 
Masami Hiramatsu <mhiramat@xxxxxxxxxx>