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

[Frank Rowand]

On 6/23/19 7:52 PM, Masami Hiramatsu wrote:
> 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 :)

But you could extend the command line paradigm to meet your needs.

> 
>>>
>>> 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 :)

No.  This is not communicating boot loader information.

> 
>> 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.

That is debugging.  Or if you want to be pedantic, a complex performance
measurement of the boot process (more than holding a stopwatch in your
hand).

Recompiling a single object file (containing the ftrace command data)
and re-linking the kernel is not a big price in that context).  Or if
you create a new communication channel, you will have the cost of
creating that data object (certainly not much different than compiling
a devicetree) and have the bootloader provide the ftrace data object
to the kernel.

> 
> 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.

Devicetree is not the universal dumping ground for communicating
information to a booting kernel.  Please create another communication
channel.

> 
> Thank you,
>