[lttng-dev] decoding tracef msg string via babeltrace API

[Milian Wolff]

On Tuesday, April 9, 2019 7:02:06 PM CEST Jérémie Galarneau wrote:
> On Tue, 9 Apr 2019 at 04:36, Milian Wolff <milian.wolff at kdab.com> wrote:
> > On Thursday, April 4, 2019 8:25:51 PM CEST Jérémie Galarneau wrote:
> > > Hi Milian,
> > > 
> > > I have pushed a fix [1] in the stable-1.5 branch that addresses the
> > > issue you have encountered with using bt_ctf_get_field_list().
> > > This makes it possible to consume a character sequence's content.
> > > 
> > > The commit message contains an example to show how to essentially
> > > perform what the 'ctf-text' format plug-in achieves by accessing the
> > > internal string field.
> > > 
> > > Let me know if that works for you and I'll release an updated version
> > > of the 1.5 branch.
> > 
> > Thank you, I'll try that out in the next days!
> > 
> > But: why can't we make bt_ctf_get_string return the string for us? Why do
> > we
> > need to reinvent the wheel in consumers of the babeltrace API? You point
> > out
> 
> Hi,
> 
> Strings, sequences and arrays are three different types in CTF.
> 
> bt_ctf_get_string() can only be used on CTF strings. In the babeltrace 1.x
> API, those are expressed through 'bt_definition's that have a
> 'bt_declaration'
> of type CTF_TYPE_STRING. It is not a general-purpose accessor to get
> a field's content as a C-string.
> 
> Changing this in the 1.x release series goes against the design of the
> API (dedicated functions per definition type) and would, arguably, be an
> ABI breaking change.
> 
> As pointed out in the commit message, bt_ctf_get_char_array() is
> a convenience function to access a character-array's contents as
> a C-string. An equivalent function could be added for sequences.
> 
> Since you pointed-out a bug in the existing API, my priority was
> in fixing that bug which prevented users from accessing the sequences'
> contents at all in the "looks like a string" case. That fix can be
> back-ported into existing releases and made available in a point-release.
> 
> Adding new APIs is an orthogonal concern. I'm not against a
> convenience function that does what you want; but it won't be
> shoe-horned into an existing one.

I see. I'll have to live with this, but note how the current situation is far 
from perfect:

There's no way to figure out the exact version of babeltrace, neither at 
compile nor at runtime. So any user of babeltrace will potentially crash when 
calling bt_ctf_get_field_list to read a string-sequence.

Looking ahead, babeltrace 2.0 is supposedly ready any time now. Is that really 
true - I've been hearing this for about two years now I think. Is there any 
documentation that shows how one would transition from the 1.0 API to 2.0? I 
notice e.g. that `include/babeltrace/ctf/iterator.h` is gone? I can only find 
Python binding API documentation, but nothing for the C API? There does seem 
to be API documentation in the code though, is the doxygen generated HTML 
hosted somewhere? Would the issue above be resolves with the 2.0 API - i.e. is 
there a single function to call to get strings-data out of either STRING, 
ARRAY or SEQUENCE trace points?

Orthogonally, can someone explain why tracelog/tracef tracepoints use a 
SEQUENCE instead of a STRING type for the data?

Thanks

-- 
Milian Wolff | milian.wolff at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3826 bytes
Desc: not available
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190410/1ef61723/attachment-0001.bin>