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

[Milian Wolff]

On Wednesday, April 10, 2019 10:57:35 AM CEST Milian Wolff via lttng-dev 
wrote:
> On Wednesday, April 10, 2019 9:56:43 AM CEST Milian Wolff wrote:
> > 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.
> 
> Additionally, the suggested approach of iterating over the individual chars
> in the sequence doesn't allow for a zero-copy approach as is done with
> bt_ctf_get_char_array or bt_ctf_get_string.
> 
> Both could be solved if a bt_ctf_get_string_sequence or similar would be
> introduced. Would this be accepted upstream, if I create a pull request, or
> is 1.5 frozen and no new API is allowed to be added?

Ping?

-- 
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/20190430/e843494c/attachment-0001.bin>