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
>> >