linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC] Allowing modules to control tracing subsystem
Date: Tue, 02 Apr 2019 08:44:31 +0300	[thread overview]
Message-ID: <87k1gdezb4.fsf@linux.intel.com> (raw)
In-Reply-To: <87h8bvffth.fsf@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]


Hi,

Felipe Balbi <felipe.balbi@linux.intel.com> writes:
> Hi guys,
>
> I've been thinking about turning my f-trace.c USB function [1] into an
> implementation of the USB Debug Class [2]. In order to support all
> requests, I would need means to control parts of the tracing subsystem,
> for example enabling and disabling tracing, flushing the trace buffer,
> changing trace buffer size, choose which trace events to enable, etc.
>
> Some of those functions (e.g. print_trace_line()) are available for
> things like trace_kdb.c [3], but they're not available for modules;
> i.e. they're not exported symbols.
>
> This will involve a rather large change to tracing subsystem however we
> could rely on such infrastructure for remote debugging of e.g. IVIs,
> phones, etc.
>
> The USB Debug Class already predicts the presence of JTAG access and
> Hardware tracing modules to be exported over USB. It also allows for
> GDB-type access. Adding our linux kernel tracing would make it into a
> complete tracing solution.
>
> In order to fully support this we would need, not only to expose some
> internal trace functions for modules, but I suppose the trace format
> would have to be slightly better defined so that it be decoded remotely
> give access to vmlinux.
>
> What do you guys think about this? Would this be something that folks
> would be interested in? Currently we can only export ftrace data, not
> trace events or anything else. Ideally we would export raw trace buffer
> entries to be decoded at a later moment.
>
> cheers
>
> [1] https://marc.info/?i=20190321094748.7031-1-felipe.balbi@linux.intel.com
> [2] https://www.usb.org/sites/default/files/documents/usb_debug_class_rev_1_0_final_0.pdf
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/trace_kdb.c#n20

A gentle reminder here.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-04-02  5:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22  8:56 [RFC] Allowing modules to control tracing subsystem Felipe Balbi
2019-04-02  5:44 ` Felipe Balbi [this message]
2019-05-24  3:05   ` Steven Rostedt

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=87k1gdezb4.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    /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).