[lttng-dev] Explicit setting of UUID with ctf writer

[Rocky Dunlap]

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 at gmail.com>
wrote:

> On Fri, Apr 7, 2017 at 4:15 PM, Rocky Dunlap <rsdunlapiv at 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 at gmail.com>
> wrote:
> >>
> >> On Fri, Apr 7, 2017 at 3:18 PM, Rocky Dunlap <rsdunlapiv at 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 at lists.lttng.org
> >> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20170407/a8db6105/attachment-0001.html>