GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > Last week packet.header part from both client-side and metadata was
> > completed. I will continue to work on adding packet.context etc.
> >
> > I got the response from lltng about stream_instance_id.
> > https://lists.lttng.org/pipermail/lttng-dev/2019-July/029093.html
>
> Ok, did you double check that the stream_instance_id is equal to the
> cpu_id in an example LTTNG file?
>
Yes. They are equal. I have attached the image of the content in HEX
format. On 2nd raw last 64 bits value is 2 and on 6th raw first 32 bits
value is also 2. The same case with other files also. Here 64 bits value is
of stream_instance_id and 32 bits value is of cpu_id.

>
> >
> > I have made changes accordingly.
> >
> https://github.com/rmeena840/rtems-tools/commit/4e9b6825687242ca60da50d3f6feed08714440a2
> >
> > I have moved the generation of binary stream files directly to
> > ./misc/record/ctf/. See above commit.
>
> Why have you changed this? The tool should output the files in the
> current directory. Please change it back to the original version.
>
The metadata file is in misc/record/ctf. The directory would look clean.
Isn't it needed?

>
> Please have a look at the fseek() function:
>
> http://man7.org/linux/man-pages/man3/fseek.3.html


Okay. I am not sure but won't this overwrite the old content in file? Since
we will be writing to the same file.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190715/e57a507b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hex values.png
Type: image/png
Size: 83199 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190715/e57a507b/attachment-0002.png>