GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

*Plan of the week:*
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

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.

Blocker:

The packet.context is needed at the starting of the binary file(just after
packet.header). The packet.context has timestamp_end which can be obtained
after processing last record item but print_item() is already writing the
record_item in the binary file. The same case is with packet_size and
content_size. These two values can be obtained after processing the last
record item in the file but we need at the starting of a binary file.

We need packet.context just after packet.header in the binary file. So as
of now, I have just added cpu_id in packet.context on both client-side and
metadata.

https://github.com/rmeena840/rtems-tools/commit/95be3ec1787a48c6ff9cf6c078f83a9f6e4b9f1f

https://github.com/rmeena840/rtems-tools/commit/96a2f658e2bd36e21dd3f304ac10e2c6fe345a17

It has no warnings.

I have one approach for it. We can try the buffer approach for it. Just
write the file packet.header and packet.context in a new binary file and
append the old file content in a new 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/b91a27e2/attachment-0002.html>