*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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
