[lttng-dev] 回复:Re: documentation about CTF event payload

[lttng-dev] 回复:Re: documentation about CTF event payload

[Mathieu Desnoyers]

Hi, 

(adding back lttng-dev in CC for the benefit of others) 

Whenever possible, we try to augment the trace data with such additional 
information at post-processing, because capturing it at run-time repeatedly ends 
up being costly. 

The lttng-analyses project contains state tracker which augment the trace data 
with mapping from file descriptor to corresponding file names (see lttnganalyses/linuxautomaton/io.py). 
I'm not sure if the Trace Compass project models this mapping between file descriptors and their 
associated file, but if not, it would be an *extremely* useful addition. 

lttng-modules already dumps the information needed to create that model: 

- lttng_statedump_file_descriptor dumps all existing file descriptors for all processes, 
- a few system calls (open, dup, dup2, dup3, close, clone(see CLONE_FILES flag), fork, 
fcntl(cmd==F_DUPFD)) allow tracking the file descriptor table state changes during the trace. 

Thanks, 

Mathieu 

----- On Nov 25, 2019, at 7:36 PM, ?? <hai.yang at magic-shield.com> wrote: 

> Hi Mathieu

> Thanks for quick response. Here let me give an example. For syscalls open, LTTng
> output filename in entry_open and output fd as ret in exit_open. It would be
> desired to output both filename and fd so we can correlate them.
> I am not sure whether there is a configuration that we can have the richest
> output regarding to syscalls.
> If not, we can modify lttng-modules to output what we need. Or any other
> recommendation?

> Regards
> Hai

> ----------

> ??????????

> --------------????--------------
> ????"Mathieu Desnoyers "<mathieu.desnoyers at efficios.com>;
> ?????2019?11?20?(???) ??10:32
> ????"??" <hai.yang at magic-shield.com>;
> ???"lttng-dev "<lttng-dev at lists.lttng.org>;
> ???Re: [lttng-dev] documentation about CTF event payload
> -----------------------------------
> For the system call payload documentation, you might want to refer to the Linux
> system call
> man pages.

> For internal kernel tracepoints like sched_switch, there is no documentation of
> the meaning of
> each field at the moment. This state is the same as the upstream Linux kernel
> trace event. You'll
> have to figure it out on your own. Documenting each field of the ~500-1000 Linux
> kernel tracepoints
> is no small task.

> Thanks,

> Mathieu

> ----- On Nov 19, 2019, at 9:25 PM, ?? <hai.yang at magic-shield.com> wrote:

>> To be more specific, I suppose we can refer to
>> instrumentation\syscalls\3.10.0-rc7\x86-64-syscalls-3.10.0-rc7 for the payload
>> format of syscall event. Is it exactly in the CTF syscall event?

>> Regards
>> Hai
>> ------------------ Original ------------------
>> From: "??"<hai.yang@magic-shield.com>;
>> Date: Mon, Nov 18, 2019 09:54 AM
>> To: "lttng-dev"<lttng-dev at lists.lttng.org>;
>> Subject: documentation about CTF event payload
>> Hi

>> As LTTng generated CTF and babeltrace parse it, we have the output as attached.
>> We saw events such as sched_switch, but the payload cannot be understood
>> easily. Where we can find the document to explain the LTTng payload and
>> parameters?

>> Regards
>> Hai

>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20191126/4627b4ff/attachment.html>

[lttng-dev] 回复:Re: documentation about CTF event payload

[杨海]

Thanks Mathieu. If I understand correctly, lttng-modules output necessary information as lttng_statedump_file_descriptor, and it is a part of CTF. But when babeltrace parse CTF, it does not process those information.
lttng-analyses is post-processing python scripts while babeltrace is realtime C parser.
If we decide to extend babeltrace to support the filename-fd mapping like iolog functionality in lttng-analyses, any recommendation?


Regards
Hai
 

------------------ Original ------------------
From: &nbsp;"Mathieu Desnoyers"<mathieu.desnoyers@efficios.com&gt;;
Date: &nbsp;Tue, Nov 26, 2019 10:47 PM
To: &nbsp;"??"<hai.yang at magic-shield.com&gt;; 
Cc: &nbsp;"lttng-dev"<lttng-dev at lists.lttng.org&gt;; "Matthew Khouzam"<matthew.khouzam at ericsson.com&gt;; "Genevi?ve Bastien"<gbastien at versatic.net&gt;; 
Subject: &nbsp;Re: ??:Re: [lttng-dev] documentation about CTF event payload

&nbsp;

Hi,



(adding back lttng-dev in CC for the benefit of others)



Whenever possible, we try to augment the trace data with such additional

information at post-processing, because capturing it at run-time repeatedly ends
up being costly.



The lttng-analyses project contains state tracker which augment the trace data

with mapping from file descriptor to corresponding file names (see lttnganalyses/linuxautomaton/io.py).
I'm not sure if the Trace Compass project models this mapping between file descriptors and their

associated file, but if not, it would be an *extremely* useful addition.



lttng-modules already dumps the information needed to create that model:



- lttng_statedump_file_descriptor dumps all existing file descriptors for all processes,

- a few system calls (open, dup, dup2, dup3, close, clone(see CLONE_FILES flag), fork,
fcntl(cmd==F_DUPFD)) allow tracking the file descriptor table state changes during the trace.


Thanks,


Mathieu







----- On Nov 25, 2019, at 7:36 PM, ?? <hai.yang at magic-shield.com&gt; wrote:

Hi Mathieu

Thanks for quick response. Here let me give an example. For syscalls open, LTTng output filename in entry_open and output fd as ret in exit_open. It would be desired to output both filename and fd so we can correlate them. 
I am not sure whether there is a configuration that we can have the richest output regarding to syscalls. 
If not, we can modify lttng-modules to output what we need. Or any other recommendation?

Regards
Hai 

----------

??????????





--------------????--------------
????"Mathieu Desnoyers "<mathieu.desnoyers at efficios.com&gt;;
?????2019?11?20?(???) ??10:32
????"??" <hai.yang at magic-shield.com&gt;;
???"lttng-dev "<lttng-dev at lists.lttng.org&gt;;
???Re: [lttng-dev] documentation about CTF event payload
-----------------------------------

 For the system call payload documentation, you might want to refer to the Linux system call

man pages.


For internal kernel tracepoints like sched_switch, there is no documentation of the meaning of

each field at the moment. This state is the same as the upstream Linux kernel trace event. You'll
have to figure it out on your own. Documenting each field of the ~500-1000 Linux kernel tracepoints
is no small task.


Thanks,


Mathieu


----- On Nov 19, 2019, at 9:25 PM, ?? <hai.yang at magic-shield.com&gt; wrote:

To be more specific, I suppose we can refer to instrumentation\syscalls\3.10.0-rc7\x86-64-syscalls-3.10.0-rc7 for the payload format of syscall event. Is it exactly in the CTF syscall event?

Regards
Hai
&nbsp;
------------------ Original ------------------
From: &nbsp;"??"<hai.yang@magic-shield.com&gt;;
Date: &nbsp;Mon, Nov 18, 2019 09:54 AM
To: &nbsp;"lttng-dev"<lttng-dev at lists.lttng.org&gt;; 
Subject: &nbsp;documentation about CTF event payload

&nbsp;
Hi

As LTTng generated CTF and babeltrace parse it, we have the output as attached. We saw events such as sched_switch, but the payload cannot be understood easily. Where we can find the document to explain the LTTng payload and parameters?

Regards
Hai




_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


-- 

Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

 





-- 

Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20191202/5aa34f1a/attachment.html>