public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Piotr Maziarz <piotrx.maziarz@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	andriy.shevchenko@intel.com, cezary.rojewski@intel.com,
	gustaw.lewandowski@intel.com
Subject: Re: [PATCH v2 2/2] tracing: Use seq_buf_hex_dump() to dump buffers
Date: Tue, 26 Nov 2019 15:53:26 +0100	[thread overview]
Message-ID: <61e34d88-bbf7-a2ff-e983-64dc9be1a482@linux.intel.com> (raw)
In-Reply-To: <20191113160922.1b1f0fc0@gandalf.local.home>

On 2019-11-13 22:09, Steven Rostedt wrote:
> OK, so the __print_hex_dump() will be exported to the format files.
> 
> Would you be willing to add a function to handle __print_hex_dump() in
> tools/lib/traceevent/event-parse.c, like __print_flags(),
> __print_symbolic(), and other __print_*() functions are handled. This
> will allow trace-cmd and perf to be able to parse the data when you
> used it via the userspace tools.
> 
> This can be a separate patch, but ideally before any trace events start
> using this.
> 
> Thanks,
> 
> -- Steve
> 

Hello Steven,

I'm writing handle in event-parse and I came across some technical 
problems. I have an event which print function looks like that:
TP_printk("%s",
	  __print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 4,
			   __get_dynamic_array(buf),
			   __get_dynamic_array_len(buf), false))
It works properly when printing events to debugfs.
I'm testing my implementation with trace-cmd and it has problem with 
parsing DUMP_PREFIX_OFFSET and false (I'm using 
alloc_and_process_delim()). Instead of having numerical values 
tep_print_args are of type TEP_PRINT_ATOM and have char array 
"DUMP_PREFIX_OFFSET" or "true".
Am I doing something incorrect? Parsing it this way is problematic 
because instead of false someone may use 0 or logic expression. And 
writing it to support all possible scenarios may be tedious and prone to 
errors.

Best regards,
Piotr Maziarz

  reply	other threads:[~2019-11-26 14:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 12:45 [PATCH v2 1/2] seq_buf: Add printing formatted hex dumps Piotr Maziarz
2019-11-07 12:45 ` [PATCH v2 2/2] tracing: Use seq_buf_hex_dump() to dump buffers Piotr Maziarz
2019-11-13 21:09   ` Steven Rostedt
2019-11-26 14:53     ` Piotr Maziarz [this message]
2019-11-26 19:51       ` Steven Rostedt
2019-11-27 10:56         ` Piotr Maziarz
2019-11-13 21:02 ` [PATCH v2 1/2] seq_buf: Add printing formatted hex dumps Steven Rostedt
2019-11-14  8:00   ` Cezary Rojewski
2019-11-14 14:35     ` 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=61e34d88-bbf7-a2ff-e983-64dc9be1a482@linux.intel.com \
    --to=piotrx.maziarz@linux.intel.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=cezary.rojewski@intel.com \
    --cc=gustaw.lewandowski@intel.com \
    --cc=linux-kernel@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