Hi Frank, On Mon, 24 Jun 2019 15:31:07 -0700 Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >>> 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. But the kernel command line is a command line. Would you mean encoding the structured setting in binary format with base64 and pass it? :( > >> 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. I found following discussion in etherpad log, https://elinux.org/Device_tree_plumbers_2016_etherpad ---- If you have data that the kernel does not have a good way to get, that's OK to put into DT. Operating points are OK - but should still be structured well. ---- This sounds like if it is structured well, and there are no other way, we will be able to use DT as a channel. > >> > >> 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. Hmm, it's a kind of communication with the operator of the boot loader, since there is an admin or developer behind it. I think the comminication is to communicate with that human. Then if they intend to trace boot process, that is a kind of communication. [...] > >>> - 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). Yeah, that's right. > Recompiling a single object file (containing the ftrace command data) > and re-linking the kernel is not a big price in that context). No, if I can use DT, I can choose one of them while boot up. That will be a big difference. (Of course for that purpose, I should work on boot loader to support DT overlay) > 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. Yes, and for me, that sounds like just a reinvention of the wheel. If I can reuse devicetree infrastructure, it is easily done (as I implemented in this series. It's just about 500LOC (and YAML document) I can clone drivers/of/ code only for that new communication channel, but that makes no one happy. :( > > 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. Why should we so limit the availability of even a small corner of existing open source software...? Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
