* Re: Explicit setting of UUID with ctf writer
[not found] ` <CAK-w0Ddo6hJsPoZLh8VdgqOcBb6sUsj6FkHrtv9UBkrf5gKDEg@mail.gmail.com>
@ 2017-04-07 22:07 ` Rocky Dunlap
2017-04-07 22:55 ` Philippe Proulx
2017-04-07 23:14 ` Philippe Proulx
2 siblings, 0 replies; 8+ messages in thread
From: Rocky Dunlap @ 2017-04-07 22:07 UTC (permalink / raw)
To: Philippe Proulx; +Cc: lttng-dev
[-- Attachment #1.1: Type: text/plain, Size: 4543 bytes --]
Phil,
Not sure about your release policy, but would it be possible to have a
1.5.3 release with a new API to set the trace uuid?
Rocky
On Fri, Apr 7, 2017 at 4:02 PM, Rocky Dunlap <rsdunlapiv@gmail.com> wrote:
> Phil,
>
> Thanks very much for your suggestion. I tried it and it does work exactly
> as you say, but I agree it is a bit ugly and non-portable. It is nice to
> have a temporary option while awaiting babeltrace 2.0.
>
> Using the command line to combine traces is perhaps the cleaner option.
> However, it does not appear that I can output in CTF format with this
> version:
>
> $ babeltrace -w combined -o ctf PET1 PET2
> [error] Only CTF traces with a single clock description are supported by
> this babeltrace version.
> [error] Opening CTF traces for output is not supported yet.
> Error opening trace "combined" for writing.
>
> Thanks,
> Rocky
>
> On Fri, Apr 7, 2017 at 3:03 PM, Philippe Proulx <eeppeliteloop@gmail.com>
> wrote:
>
>> On Fri, Apr 7, 2017 at 4:15 PM, Rocky Dunlap <rsdunlapiv@gmail.com>
>> wrote:
>> > Phil,
>> >
>> > This relates to my previous question about multi-process tracing. The
>> > workaround I am attempting is to have each process write its own trace
>> with
>> > a single stream, but then to pull all the stream files together into a
>> > single trace with one metadata file. For this reason the uuids would
>> need to
>> > match.
>> >
>> > Do you think this will work?
>>
>> First question: why not having multiple traces (multiple directories
>> with multiple `metadata` files)? babeltrace(1) and Trace Compass can
>> merge them easily.
>>
>> In the meantime, if you really want a single trace, here's a hack.
>> Please don't tell anyone that I suggested this. Choose any generated
>> `metadata` file which contains all the `event` blocks that you need.
>> Note that, across all your traces, the order in which you add the event
>> class objects to your single stream class object needs to remain the
>> same so that they have the same IDs whatever the trace. Then, this
>> works, as long as you use the Babeltrace 1.5.2 release:
>>
>> #include <babeltrace/ctf-writer/writer.h>
>> #include <string.h>
>> #include <assert.h>
>>
>> typedef unsigned char uuid_t[16];
>>
>> struct bt_ref {
>> long count;
>> void *release;
>> };
>>
>> struct bt_object {
>> struct bt_ref ref_count;
>> void *release;
>> void *parent;
>> };
>>
>> struct bt_ctf_trace {
>> struct bt_object base;
>> int frozen;
>> unsigned char uuid[16];
>> };
>>
>> struct bt_ctf_writer {
>> struct bt_object base;
>> int frozen;
>> struct bt_ctf_trace *trace;
>> };
>>
>> int main(void)
>> {
>> struct bt_ctf_writer *writer;
>> const unsigned char my_custom_uuid[16] = {
>> 0xb3, 0x38, 0x4d, 0x7b, 0x77, 0x8a, 0x4f, 0xf0,
>> 0x99, 0xbd, 0x43, 0x54, 0x9e, 0xc0, 0x54, 0x1b,
>> };
>>
>> writer = bt_ctf_writer_create("/tmp/my-trace");
>> assert(writer);
>> memcpy(writer->trace->uuid, my_custom_uuid, 16);
>>
>> /* do stuff with writer here */
>>
>> bt_ctf_writer_put(writer);
>> return 0;
>> }
>>
>> Again, I don't condone this: it's not portable, it's ugly, but it does
>> what you ask.
>>
>> Another hack: search the byte sequences c1 fc 1f c1 (big endian) or
>> c1 1f fc c1 (little endian) in all your stream files and replace the
>> _next_ 16 bytes with your favorite UUID. Also replace the `uuid`
>> attribute in the chosen `metadata` file with the canonical
>> representation of your favorite UUID.
>>
>> Phil
>>
>> >
>> > Rocky
>> >
>> > On Apr 7, 2017 1:57 PM, "Philippe Proulx" <eeppeliteloop@gmail.com>
>> wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 3:18 PM, Rocky Dunlap <rsdunlapiv@gmail.com>
>> wrote:
>> >> > Is it possible to explicitly set a uuid for a trace using the
>> Babeltrace
>> >> > CTF
>> >> > writer? I did not see a straightforward way to do it with the API.
>> >>
>> >> It's not possible as of Babeltrace 1. We'll add trace UUID accessors to
>> >> the upcoming Babeltrace 2 API.
>> >>
>> >> That said, may I ask you why you need this? Two different CTF traces
>> >> should not share the same UUID.
>> >>
>> >> Phil
>> >>
>> >> >
>> >> > Rocky
>> >> >
>> >> > _______________________________________________
>> >> > lttng-dev mailing list
>> >> > lttng-dev@lists.lttng.org
>> >> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >> >
>>
>
>
[-- Attachment #1.2: Type: text/html, Size: 6447 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Explicit setting of UUID with ctf writer
[not found] ` <CAK-w0Ddo6hJsPoZLh8VdgqOcBb6sUsj6FkHrtv9UBkrf5gKDEg@mail.gmail.com>
2017-04-07 22:07 ` Rocky Dunlap
@ 2017-04-07 22:55 ` Philippe Proulx
2017-04-07 23:14 ` Philippe Proulx
2 siblings, 0 replies; 8+ messages in thread
From: Philippe Proulx @ 2017-04-07 22:55 UTC (permalink / raw)
To: Rocky Dunlap; +Cc: lttng-dev
On Fri, Apr 7, 2017 at 6:02 PM, Rocky Dunlap <rsdunlapiv@gmail.com> wrote:
> Phil,
>
> Thanks very much for your suggestion. I tried it and it does work exactly
> as you say, but I agree it is a bit ugly and non-portable. It is nice to
> have a temporary option while awaiting babeltrace 2.0.
>
> Using the command line to combine traces is perhaps the cleaner option.
> However, it does not appear that I can output in CTF format with this
> version:
>
> $ babeltrace -w combined -o ctf PET1 PET2
> [error] Only CTF traces with a single clock description are supported by
> this babeltrace version.
> [error] Opening CTF traces for output is not supported yet.
> Error opening trace "combined" for writing.
Did you try with --clock-force-correlate?
Phil
>
> Thanks,
> Rocky
>
> On Fri, Apr 7, 2017 at 3:03 PM, Philippe Proulx <eeppeliteloop@gmail.com>
> wrote:
>>
>> On Fri, Apr 7, 2017 at 4:15 PM, Rocky Dunlap <rsdunlapiv@gmail.com> wrote:
>> > Phil,
>> >
>> > This relates to my previous question about multi-process tracing. The
>> > workaround I am attempting is to have each process write its own trace
>> > with
>> > a single stream, but then to pull all the stream files together into a
>> > single trace with one metadata file. For this reason the uuids would
>> > need to
>> > match.
>> >
>> > Do you think this will work?
>>
>> First question: why not having multiple traces (multiple directories
>> with multiple `metadata` files)? babeltrace(1) and Trace Compass can
>> merge them easily.
>>
>> In the meantime, if you really want a single trace, here's a hack.
>> Please don't tell anyone that I suggested this. Choose any generated
>> `metadata` file which contains all the `event` blocks that you need.
>> Note that, across all your traces, the order in which you add the event
>> class objects to your single stream class object needs to remain the
>> same so that they have the same IDs whatever the trace. Then, this
>> works, as long as you use the Babeltrace 1.5.2 release:
>>
>> #include <babeltrace/ctf-writer/writer.h>
>> #include <string.h>
>> #include <assert.h>
>>
>> typedef unsigned char uuid_t[16];
>>
>> struct bt_ref {
>> long count;
>> void *release;
>> };
>>
>> struct bt_object {
>> struct bt_ref ref_count;
>> void *release;
>> void *parent;
>> };
>>
>> struct bt_ctf_trace {
>> struct bt_object base;
>> int frozen;
>> unsigned char uuid[16];
>> };
>>
>> struct bt_ctf_writer {
>> struct bt_object base;
>> int frozen;
>> struct bt_ctf_trace *trace;
>> };
>>
>> int main(void)
>> {
>> struct bt_ctf_writer *writer;
>> const unsigned char my_custom_uuid[16] = {
>> 0xb3, 0x38, 0x4d, 0x7b, 0x77, 0x8a, 0x4f, 0xf0,
>> 0x99, 0xbd, 0x43, 0x54, 0x9e, 0xc0, 0x54, 0x1b,
>> };
>>
>> writer = bt_ctf_writer_create("/tmp/my-trace");
>> assert(writer);
>> memcpy(writer->trace->uuid, my_custom_uuid, 16);
>>
>> /* do stuff with writer here */
>>
>> bt_ctf_writer_put(writer);
>> return 0;
>> }
>>
>> Again, I don't condone this: it's not portable, it's ugly, but it does
>> what you ask.
>>
>> Another hack: search the byte sequences c1 fc 1f c1 (big endian) or
>> c1 1f fc c1 (little endian) in all your stream files and replace the
>> _next_ 16 bytes with your favorite UUID. Also replace the `uuid`
>> attribute in the chosen `metadata` file with the canonical
>> representation of your favorite UUID.
>>
>> Phil
>>
>> >
>> > Rocky
>> >
>> > On Apr 7, 2017 1:57 PM, "Philippe Proulx" <eeppeliteloop@gmail.com>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 3:18 PM, Rocky Dunlap <rsdunlapiv@gmail.com>
>> >> wrote:
>> >> > Is it possible to explicitly set a uuid for a trace using the
>> >> > Babeltrace
>> >> > CTF
>> >> > writer? I did not see a straightforward way to do it with the API.
>> >>
>> >> It's not possible as of Babeltrace 1. We'll add trace UUID accessors to
>> >> the upcoming Babeltrace 2 API.
>> >>
>> >> That said, may I ask you why you need this? Two different CTF traces
>> >> should not share the same UUID.
>> >>
>> >> Phil
>> >>
>> >> >
>> >> > Rocky
>> >> >
>> >> > _______________________________________________
>> >> > lttng-dev mailing list
>> >> > lttng-dev@lists.lttng.org
>> >> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >> >
>
>
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Explicit setting of UUID with ctf writer
[not found] ` <CAK-w0Ddo6hJsPoZLh8VdgqOcBb6sUsj6FkHrtv9UBkrf5gKDEg@mail.gmail.com>
2017-04-07 22:07 ` Rocky Dunlap
2017-04-07 22:55 ` Philippe Proulx
@ 2017-04-07 23:14 ` Philippe Proulx
2 siblings, 0 replies; 8+ messages in thread
From: Philippe Proulx @ 2017-04-07 23:14 UTC (permalink / raw)
To: Rocky Dunlap; +Cc: lttng-dev
On Fri, Apr 7, 2017 at 6:02 PM, Rocky Dunlap <rsdunlapiv@gmail.com> wrote:
> Phil,
>
> Thanks very much for your suggestion. I tried it and it does work exactly
> as you say, but I agree it is a bit ugly and non-portable. It is nice to
> have a temporary option while awaiting babeltrace 2.0.
>
> Using the command line to combine traces is perhaps the cleaner option.
> However, it does not appear that I can output in CTF format with this
> version:
>
> $ babeltrace -w combined -o ctf PET1 PET2
> [error] Only CTF traces with a single clock description are supported by
> this babeltrace version.
> [error] Opening CTF traces for output is not supported yet.
> Error opening trace "combined" for writing.
And no, babeltrace(1) 1.5.2 cannot produce CTF traces. Why do you want
to combine different traces as a single trace? How do you want to
analyze this combination ultimately?
By the way, babeltrace(1) 2.0.0 will be able to combine different format
of traces from different sources as a single CTF trace like you want to
do.
Phil
>
> Thanks,
> Rocky
>
> On Fri, Apr 7, 2017 at 3:03 PM, Philippe Proulx <eeppeliteloop@gmail.com>
> wrote:
>>
>> On Fri, Apr 7, 2017 at 4:15 PM, Rocky Dunlap <rsdunlapiv@gmail.com> wrote:
>> > Phil,
>> >
>> > This relates to my previous question about multi-process tracing. The
>> > workaround I am attempting is to have each process write its own trace
>> > with
>> > a single stream, but then to pull all the stream files together into a
>> > single trace with one metadata file. For this reason the uuids would
>> > need to
>> > match.
>> >
>> > Do you think this will work?
>>
>> First question: why not having multiple traces (multiple directories
>> with multiple `metadata` files)? babeltrace(1) and Trace Compass can
>> merge them easily.
>>
>> In the meantime, if you really want a single trace, here's a hack.
>> Please don't tell anyone that I suggested this. Choose any generated
>> `metadata` file which contains all the `event` blocks that you need.
>> Note that, across all your traces, the order in which you add the event
>> class objects to your single stream class object needs to remain the
>> same so that they have the same IDs whatever the trace. Then, this
>> works, as long as you use the Babeltrace 1.5.2 release:
>>
>> #include <babeltrace/ctf-writer/writer.h>
>> #include <string.h>
>> #include <assert.h>
>>
>> typedef unsigned char uuid_t[16];
>>
>> struct bt_ref {
>> long count;
>> void *release;
>> };
>>
>> struct bt_object {
>> struct bt_ref ref_count;
>> void *release;
>> void *parent;
>> };
>>
>> struct bt_ctf_trace {
>> struct bt_object base;
>> int frozen;
>> unsigned char uuid[16];
>> };
>>
>> struct bt_ctf_writer {
>> struct bt_object base;
>> int frozen;
>> struct bt_ctf_trace *trace;
>> };
>>
>> int main(void)
>> {
>> struct bt_ctf_writer *writer;
>> const unsigned char my_custom_uuid[16] = {
>> 0xb3, 0x38, 0x4d, 0x7b, 0x77, 0x8a, 0x4f, 0xf0,
>> 0x99, 0xbd, 0x43, 0x54, 0x9e, 0xc0, 0x54, 0x1b,
>> };
>>
>> writer = bt_ctf_writer_create("/tmp/my-trace");
>> assert(writer);
>> memcpy(writer->trace->uuid, my_custom_uuid, 16);
>>
>> /* do stuff with writer here */
>>
>> bt_ctf_writer_put(writer);
>> return 0;
>> }
>>
>> Again, I don't condone this: it's not portable, it's ugly, but it does
>> what you ask.
>>
>> Another hack: search the byte sequences c1 fc 1f c1 (big endian) or
>> c1 1f fc c1 (little endian) in all your stream files and replace the
>> _next_ 16 bytes with your favorite UUID. Also replace the `uuid`
>> attribute in the chosen `metadata` file with the canonical
>> representation of your favorite UUID.
>>
>> Phil
>>
>> >
>> > Rocky
>> >
>> > On Apr 7, 2017 1:57 PM, "Philippe Proulx" <eeppeliteloop@gmail.com>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 3:18 PM, Rocky Dunlap <rsdunlapiv@gmail.com>
>> >> wrote:
>> >> > Is it possible to explicitly set a uuid for a trace using the
>> >> > Babeltrace
>> >> > CTF
>> >> > writer? I did not see a straightforward way to do it with the API.
>> >>
>> >> It's not possible as of Babeltrace 1. We'll add trace UUID accessors to
>> >> the upcoming Babeltrace 2 API.
>> >>
>> >> That said, may I ask you why you need this? Two different CTF traces
>> >> should not share the same UUID.
>> >>
>> >> Phil
>> >>
>> >> >
>> >> > Rocky
>> >> >
>> >> > _______________________________________________
>> >> > lttng-dev mailing list
>> >> > lttng-dev@lists.lttng.org
>> >> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >> >
>
>
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply [flat|nested] 8+ messages in thread