Hi Masami, Note that Masami has submitted v2 of the patch with further discussion. I noticed that I had left some comments unanswered in this thread, so I am doing this reply before moving on to reply to the v2 thread. Feel free to move the discussion to v2 instead of replying to this email if you find that easier. On 6/24/19 10:00 PM, Masami Hiramatsu wrote: > 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? :( If you want to put structured data in the command line, then yes, you could use an ascii safe form, such as base64, to contain it. If that is what you want. > >>>> 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. The quote from the plumbers 2016 devicetree etherpad ("Operating points are OK ...) conveniently ignores a sentence just a few lines later: "If firmware is deciding the operating point, then it's OK to convey it via DT." The operating points example is clearly communicating boot loader information to the kernel. Something the admin or developer wants to communicate is not boot loader information. > > [...] >>>>> - 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) This is debugging kernel drivers. I do not think that it is a big cost for a kernel developer to re-link the kernel. On any reasonable modern development system this should be a matter of seconds, not minutes. Compiling a devicetree source is not significantly less time. (To be fair, you imply that you would have various compiled devicetrees to choose from at boot time. It may be realistic to have a library of ftrace commands, or it may be more realistic that someone debugging a kernel driver will create a unique ftrace command set for the particular case they are debugging.) > >> 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) Or you can just use the existing ftrace boot command line syntax. > > 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...? Because the proposal is a mis-use of devicetree. > > Thank you, >
