devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Rob Herring <robh+dt@kernel.org>,
	Tom Zanussi <tom.zanussi@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree
Date: Wed, 17 Jul 2019 09:57:36 +0900	[thread overview]
Message-ID: <20190717095736.c53f0368034a11332346d18e@kernel.org> (raw)
In-Reply-To: <c01bd567-0c8b-ec32-773b-fb95bfcdcd50@gmail.com>

Hi Frank,

On Mon, 15 Jul 2019 06:55:40 -0700
Frank Rowand <frowand.list@gmail.com> wrote:

> > 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.

But the cmdline (bootargs) is already supported, I think this is a kind of bootargs.

> > [...]
> >>>>> - 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.

Tracing is not only debugging the kernel drivers, but also measures
performance or behavior and compare with different settings.
Also, in some case, we can not change the binary, like distro kernel.

> 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.)

Yeah, devicetree build time may not be matter, decoupling from the
kernel image is, I think, the key point.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2019-07-17  0:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21 16:18 [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 01/11] tracing: Apply soft-disabled and filter to tracepoints printk Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 02/11] tracing: kprobes: Output kprobe event to printk buffer Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 03/11] tracing: Expose EXPORT_SYMBOL_GPL symbol Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 04/11] tracing: kprobes: Register to dynevent earlier stage Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 05/11] tracing: Accept different type for synthetic event fields Masami Hiramatsu
2019-06-21 16:18 ` [RFC PATCH 06/11] tracing: Add NULL trace-array check in print_synth_event() Masami Hiramatsu
2019-06-21 16:19 ` [RFC PATCH 07/11] dt-bindings: tracing: Add ftrace binding document Masami Hiramatsu
2019-06-21 16:19 ` [RFC PATCH 08/11] tracing: of: Add setup tracing by devicetree support Masami Hiramatsu
2019-06-21 16:19 ` [RFC PATCH 09/11] tracing: of: Add trace event settings Masami Hiramatsu
2019-06-21 16:19 ` [RFC PATCH 10/11] tracing: of: Add kprobe event support Masami Hiramatsu
2019-06-21 16:19 ` [RFC PATCH 11/11] tracing: of: Add synthetic " Masami Hiramatsu
2019-06-23 19:58 ` [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree Frank Rowand
2019-06-24  2:52   ` Masami Hiramatsu
2019-06-24 22:31     ` Frank Rowand
2019-06-25  5:00       ` Masami Hiramatsu
2019-07-15 13:55         ` Frank Rowand
2019-07-17  0:57           ` Masami Hiramatsu [this message]
2019-06-26 21:58 ` Rob Herring
2019-06-27  2:55   ` Frank Rowand
2019-06-27 10:58   ` Masami Hiramatsu
2019-07-02  9:47     ` Masami Hiramatsu
2019-07-02 13:30       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190717095736.c53f0368034a11332346d18e@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=acme@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tom.zanussi@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).