[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190624115223.db1e53549a15c6548bfa1fa1@kernel.org>
Date: Mon, 24 Jun 2019 11:52:23 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Frank Rowand <frowand.list@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Rob Herring <robh+dt@...nel.org>,
Tom Zanussi <tom.zanussi@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [RFC PATCH 00/11] tracing: of: Boot time tracing using
devicetree
Hi Frank,
Thank you for your comment!
On Sun, 23 Jun 2019 12:58:45 -0700
Frank Rowand <frowand.list@...il.com> 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@...nel.org>
Powered by blists - more mailing lists