[lkml]   [2019]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree
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 <> 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:
> 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

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

> Thank you,

 \ /
  Last update: 2019-06-25 00:31    [W:0.076 / U:2.000 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site