On Thu, May 29, 2014 at 09:12:51AM -0400, Steven Rostedt wrote:
> What do you think gets recorded in the ring buffer? The pointer to the
> string? No! You copy the entire string into the ring buffer, with
> markers and all. How big is that string? 60 chars? 80? I see you
> recording meta data there too:
I'm not the expert of trace. If I am wrong please fix me. So it looks
like all trace data shhould be pushed into the ring buffer as raw
material and when it is needed to be printed via TP_printk, these
raw data will be expanded(unzip them as you told) into another
temp buffer, maybe kernel printk buffer directly.
[...]
> > #define show_dimm_location(type) \
> > __print_symbolic(type, \
> > { CPER_MEM_VALID_NODE, "node" }, \
> > { CPER_MEM_VALID_CARD, "card" }, \
> > { CPER_MEM_VALID_MODULE, "module" }, \
> > ...
> >
>
> I'm not sure you could use that, as you save an array of data. The
> print_symbolic() wont work with an array.
Just FWIW, call it again and again. But it looks too awkward I will
use other style.
>
> You can still use the same code for both the tracepoint (perf and
> ftrace) and for dmesg. You need to write a packed array that is
> returned as well as a way to convert that array into a human readable
> string for later processing. The dmesg version would just have them
> both together where as the tracepoint records the packed version on the
> ring buffer and the TP_printk() will use the extraction.
>
> That is, dmesg has the compress and extraction in one place where the
> tracepoint has them in two different places.
>
> Understand?
Yes, I feel the same way. Zip/unzip is unavoidable.
Attachment:
signature.asc
Description: Digital signature
