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>
