[lttng-dev] [RFC babeltrace 1/2] fs-src: add argument for metadata src dir

[Alexander Aring]

Hi,

On Tue, May 01, 2018 at 11:22:18AM -0400, Philippe Proulx wrote:
...
> >
> > I also thought about: using barectf and generate a object file linked
> > to my platform who has the metadata file inside and will be created to
> > my stream file when barectf init's (if it's not already exists).
> > So far I see it could be done because metadata file is compile time
> > related and binded to barectf generated code.
> 
> Yes this is a better idea. If you cannot postprocess the trace directories,
> than it's better that you create valid traces in the beginning.
> 

I see, I will have this idea in the background... I think I will switch
to it when I see some issues with metadata and this would avoid it.

> >
> > That will bloat my binary as one disadvantage, otherwise I can be sure
> > there is no mixed metadata handling everywhere.
> 
> Can you create symbolic links on this filesystem (when you have write
> access)? This would avoid bloating.
> 

I will switch to symbolic link and hopefully nobody will pack everything
in a .zip or something else that doesn't support symbolic links. :-)

> >
> >> Also, do your CTF traces have UUIDs? If they do, they should all be
> >> different, but having the same metadata file makes them all the same.
> >> This is not valid either.
> >>
> >
> > I have UUID but my applications use all the same metadata file by
> > barectf. :-) I hope this is a valid point?
> 
> Normally, a trace has a unique UUID. If you cannot ensure this, I
> suggest that you remove the UUID field from the packet header.
> 

I see, according [0]:

Trace UUID, used to ensure the event packet match the metadata used.
Note: we cannot use a metadata checksum in every cases instead of a UUID
because metadata can be appended to while tracing is active. This field
is optional.

---

Will this drop not a validation for me that the stream and metadata fits
together? So babeltrace will reject something when stream was made with
a different metadata as placed into my TRACES directory?

Somebody could use a different metadata file, by weird accident.

And "... metadata can be appended to while tracing is active." - woa, so
you can add more metadata during runtime and the streams can use them
(during runtime)?

I guess this is not possible with barectf where everything is made at
compile time... (currently).

- Alex

[0] http://diamon.org/ctf/#spec5