[lttng-dev] lttng questions

[Nalin Pai]

Is there an ETA for 2.11?

-Nalin

On Wed, Jul 19, 2017 at 1:24 PM, Philippe Proulx <eeppeliteloop at gmail.com>
wrote:

> On Wed, Jul 19, 2017 at 3:05 PM, Nalin Pai <nalinpai at gmail.com> wrote:
> > More questions.
> >
> > I notice that filter expression parser does not validate to check if the
> > field-name in the expression is valid or whether the expression value is
> > consistent with the field type (e.g check that expression value is
> integer
> > if field type is integer). Are there any plans of stricter checking of
> > expressions? If the user makes a mistake while typing out the expression
> is
> > there any feedback to indicate the error?
>
> It cannot be indicated to the user at event rule creation time
> (lttng enable-event) because future events could match an event rule
> you create now.
>
> When a field's type is not what it should be according to the event
> rule's filter expression, then the whole filter expression evaluates to
> 0 (false), thus the whole event rule is considered not satisfied.
>
> >
> > Thanks,
> > Nalin
> >
> > On Wed, Jul 19, 2017 at 10:11 AM, Nalin Pai <nalinpai at gmail.com> wrote:
> >>
> >> Thanks for your answers. I have a question on event filters. We will be
> >> representing IPv6 addresses as arrays of bytes. We would like to be
> able to
> >> filter on IPv6 address fields. Does lttng filtering on arrays and
> sequences?
> >> If yes, then what's the filter expression format for this.
>
> This is an upcoming feature, probably part of 2.11, but I could be wrong
> (about the version).
>
> Phil
>
> >>
> >> Thanks,
> >> Nalin
> >>
> >>
> >>
> >> On Sun, Jul 16, 2017 at 4:49 PM, Philippe Proulx <
> eeppeliteloop at gmail.com>
> >> wrote:
> >>>
> >>> On Sun, Jul 16, 2017 at 2:28 PM, Nalin Pai <nalinpai at gmail.com> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > We are looking at using lttng as a solution for all our trace and
> debug
> >>> > requirements. We want to get away from traditional file based string
> format
> >>> > logging and move to lttng, which then gives us the flexibility of
> dumping
> >>> > the traces to file or the network. With this background, I have
> several
> >>> > questions for the team.
> >>> >
> >>> > 1) CTF supports struct fields. I don’t see any ctf_ macros in lttng
> >>> > that will allow us to define tracepoints having struct fields. Is
> there a
> >>> > way to do this that I am missing?
> >>>
> >>> Complex CTF types (except a few very specific exceptions) are not
> >>> supported in LTTng-UST, the user space LTTng tracer. If you need a
> >>> structure data type, then you need to "explode" it, perhaps with field
> >>> name prefixes, as of the latest version of LTTng. For example:
> >>> `my_struct_user_id`, `my_struct_msg_id`, `my_struct_msg`.
> >>>
> >>> >
> >>> > 2) Display hints. Sometimes there is a need to display certain fields
> >>> > in a particular way, e.g. IP and MAC addresses. While the tracepoint
> >>> > definition for these fields are going to be integers or sequences of
> >>> > integers, we would like babeltrace to display these fields in a
> certain
> >>> > format. Short of modifying babeltrace to recognize these fields by
> their
> >>> > names and handle them specially, is there any other way of achieving
> the
> >>> > same?
> >>>
> >>> In the short- to medium-term, with Babeltrace 2.0 (currently in "pre"
> >>> development stage), you can create your own sink component to do
> >>> something with events. The default textual display is called
> >>> sink.text.pretty. If you need a modified version of this sink
> >>> component class, you could copy its source and create your own
> >>> modified plugin which, as you wrote, would recognize the fields by
> >>> name, etc. You could then run the CLI as such:
> >>>
> >>>     babeltrace /path/to/trace
> >>> --component=sink.my-plugin.my-component-class
> >>>
> >>> I can't comment on Trace Compass/LTTng Scope.
> >>>
> >>> I see no other way for the moment. CTF 2 will have a way to indicate
> >>> that specific fields are to be displayed using a given format string,
> >>> for example, but its specification is not available currently (only a
> >>> proposal is available here
> >>> <http://diamon.org/ctf/files/CTF2-PROP-1.0.html>). Babeltrace 2.1 will
> >>> support CTF 2, after which a future version of LTTng will produce it.
> >>>
> >>> Phil
> >>>
> >>> >
> >>> > -Nalin
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > 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/20170719/c5fa9d50/attachment.html>