Philippe Proulx [Mon, 12 Aug 2019 22:15:04 +0000 (18:15 -0400)]
sink.text.pretty: print option fields
The component prints `<none>` when there's no current optional field,
and does the same as a variant field otherwise (printing the optional
field's value between `{` and `}`).
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I7a42ca31d68562fa0994945b32dbb2935aa92ee4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1899 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Mon, 12 Aug 2019 21:09:38 +0000 (17:09 -0400)]
lib: add option field class and field types
This patch adds the option field class (FC) and field to the available
library types.
An option field can contain or not another field. It is very similar to
a variant field in that it's a choice between two things.
CTF 2 will very likely have such a type, so Babeltrace 2.0 will be
ready.
Like a variant FC, an option FC can have a selector which must be a
reachable boolean FC.
When you create an option with bt_field_class_option_create(), you pass
the optional FC, which becomes frozen on success.
You can borrow the optional FC of an option FC with
bt_field_class_option_borrow_field_class_const(). If the option FC has a
selector FC, you can borrow the computed selector field path with
bt_field_class_option_borrow_selector_field_path_const().
To set whether or not an option field contains a field, call
bt_field_option_set_has_field(). You must call this function even if the
option field contains no field (with `BT_FALSE`) because field objects
are pooled and not reset for each message in production mode (similar to
how you must initially call bt_field_string_clear() before you call
bt_field_string_append()). Once you have called
bt_field_option_set_has_field() with `BT_TRUE`, you can borrow the
optional field with bt_field_option_borrow_field() to fill it.
On the const side, you can borrow an option field's optional field with
bt_field_option_borrow_field_const(). This function returns `NULL` if
the option field does not contain a field.
This patch also adds the
`BT_FIELD_PATH_ITEM_TYPE_CURRENT_OPTION_CONTENT` field path item type.
Such a field path item means the current field of an option field.
This patch does not adapt existing plugins and the Python bindings to
use and wrap the new option FC and field; this work is reserved
for subsequent patches.
Philippe Proulx [Mon, 12 Aug 2019 02:04:08 +0000 (22:04 -0400)]
bt2: add boolean field class and field support
This patch adds boolean field class and field support to the Python
bindings.
A boolean field class has no properties.
A boolean field is a numeric field (like Python's `bool` is a numeric
type). The `BoolFieldTestCase` test case inherits `_TestNumericField`,
making sure the field behaves more or less like the Python `bool` type.
`BoolFieldTestCase` is very similar to `BoolValueTestCase`.
Just like `BoolValue` objects, you can set the value of a `BoolField`
object from a `bool` or `BoolField` object.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib6d0723d69709b7f3b459ba173eb7cbea5d8c435
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1896 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sun, 11 Aug 2019 16:03:55 +0000 (12:03 -0400)]
sink.ctf.fs: write boolean field classes and fields
This patch makes a `sink.ctf.fs` component handle boolean field classes
and fields. Because CTF 1.8 has no boolean field class type, it makes a
best effort and translates it to an 8-bit unsigned integer field class.
A boolean field is written as an 8-bit unsigned integer field having the
value 0 (false) or 1 (true).
When a `src.ctf.fs` component reads a trace generated by `sink.ctf.fs`
where the input trace IR contained boolean field classes, the 8-bit
unsigned integer field classes will stay integer field classes; the
source component has no way to determine if the metadata describes a
boolean field class or a genuine integer field class. However, the CTF
1.8 to CTF 1.8 scenario will always be unambiguous because a
`src.ctf.fs` component never creates boolean field classes.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I6be5967c2312bdb0e67be7db14ab663912872403
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1895 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Sun, 11 Aug 2019 15:20:14 +0000 (11:20 -0400)]
lib: add boolean field class and field types
This patch adds the boolean field class and field to the available
library types. They are analogous to the boolean value object which
already exists.
CTF 2 will very likely have such a type, so Babeltrace 2.0 will be
ready.
This patch does not adapt existing plugins and the Python bindings to
use and wrap the new boolean field class and field; this work is
reserved for subsequent patches.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I90874f214757ad67d5eecaad5bd8297b8610c001
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1891 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Simon Marchi [Tue, 13 Aug 2019 19:30:15 +0000 (15:30 -0400)]
tests: return 0 instead of None for unknown file in test component class support-info query
I noticed some spurious warnings while running
TestAutoDiscoverSourceComponentSpecsGrouping.test_grouping (shortened
for brevity):
unexpected result type: component-class-name=source.test.TestSourceExt, input=/home/smarchi/src/babeltrace/tests/data/auto-source-discovery/grouping/bt_plugin_test.py, input-type=file, expected-types=REAL,MAP,SIGNED_INTEGER, actual-type=NULL
Indeed, the _query method of TestSourceExt fails to return a value (so
it returns None) if it doesn't know the file. This is not on purpose in
this test, so fix it.
Change-Id: I303c78dae4a518c62573263aa7a3afafd0c61ed7 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1906 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Jonathan Rajotte [Tue, 13 Aug 2019 22:51:32 +0000 (18:51 -0400)]
Use uuid as first comparison criteria
This is most important in the message ordering reproducibility against
multiple sources where some might populate the trace name and some don't.
A good example of a source not populating the trace name is lttng-live.
It facilitates the testing of lttng-live source plugin since it is
possible to compare it to the src.ctf.fs plugin directly.
Philippe adds: there's a trace UUID property in a CTF metadata stream,
but no trace name property. The trace name is entirely up to the
specific CTF source component class. Therefore it's safer to use the
UUID to distinguish unique traces.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I39f3c513e27bffd51ca02b089c097ac406e3316e
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1914
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Fix: src.ctf.lttng-live: missing ordering within traces and streams
Issue
=====
Sorting of messages with the same timestamps are different from the
messages sorted by the a `flt.utils.muxer` component. This is caused by
the fact that we are not sorting messages within sessions and traces
but only across the different session currently handled by the
component.
Indeed, we need to sort messages at across three locations in the code
to ensure proper ordering: sessions, traces, and streams.
Solution
========
Handle messages with the same timestamps at each of these three
locations using the `common_muxing_compare_messages()` function.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Iadc66f3b6a12f34522f6364b3f47f15eefa87930
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1888 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Mon, 12 Aug 2019 03:01:00 +0000 (23:01 -0400)]
bt2: `TraceCollectionMessageIterator`: find greatest MIP version
This patch makes the `TraceCollectionMessageIterator` object use
bt2.get_greatest_operative_mip_version() to find the greatest operative
MIP version of all the components to create, including the stream
intersection `flt.utils.trimmer` components, and then use the result to
create the graph with bt2.Graph().
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Id9024a2343d0e99384ae62bd77754912a4267dac
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1881 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sun, 11 Aug 2019 06:36:41 +0000 (02:36 -0400)]
cli: find greatest operative MIP version to create `run` command's graph
This patch makes the CLI's `run` command use
bt_get_greatest_operative_mip_version() to find the greatest operative
MIP version of all the components to create, including the stream
intersection `flt.utils.trimmer` components, and then use the result to
create the graph with bt_graph_create().
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I2e791ac9c8806457fa850d0dad72ea3ab6912f08
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1879 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sun, 11 Aug 2019 03:24:13 +0000 (23:24 -0400)]
lib: bt_graph_create(): accept MIP version
This patch makes bt_graph_create() accept the message interchange
protocol (MIP) version with which to configure the graph.
This MIP version will usually come from
bt_get_greatest_operative_mip_version() or bt_get_maximal_mip_version().
The components can access the configured MIP version with
bt_self_component_get_graph_mip_version().
As of this patch the only possible MIP version is 0. bt_graph_create()
does not accept a MIP version that is greater than
bt_get_maximal_mip_version() because almost all the library functions
need to know the configured MIP version to behave accordingly, should
the semantics change in the future.
In Python, Graph.__init__() accepts a `mip_version` parameter which
defaults to 0. A Python component can get the configured MIP version of
its operating graph with the `_UserComponent._graph_mip_version`
property.
All the sites where bt_graph_create() is called pass 0 to it. This is
correct for tests as we always control the component classes and
initialization parameters, so we know that 0 is always supported by
them. The locations where bt_get_greatest_operative_mip_version() must
be used are the CLI and `bt2.TraceCollectionMessageIterator`. Those
sites will be addressed by subsequent patches.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I324a317922a8caa5557043ae02b97e58fc91d92d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1878 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Those new functions wrap bt_get_greatest_operative_mip_version() and
bt_get_maximal_mip_version().
bt2.get_greatest_operative_mip_version() excepts a list of
`bt2.ComponentDescriptor` objects. The function builds a component
descriptor set (bt_component_descriptor_set_create()) and adds the
corresponding component descriptors to it and then calls
bt_get_greatest_operative_mip_version().
bt_get_greatest_operative_mip_version() translates
`BT_GET_OPERATIVE_MIP_VERSION_STATUS_NO_MATCH` into `None`.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Iaeb36b976f3c651fa82a86de2e835f782d682299
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1877 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Mon, 12 Aug 2019 21:19:46 +0000 (17:19 -0400)]
bt2: add "get supported MIP versions" method support
This patch makes the `bt2` package wrap the library's "get supported MIP
versions" component class method.
In a Python component class, it is expected that the optional
_user_get_supported_mip_versions() method returns either a
`bt2.UnsignedIntegerRangeSet` object or what such an object needs to be
constructed. In other words, the method can return, for example:
return [0, 1, (3, 5)]
Like in the library, the default _user_get_supported_mip_versions()
returns 0 (only protocol 0 supported):
_bt_get_supported_mip_versions_from_native() returns a new reference on
this unsigned integer range set. Then, the native
component_class_get_supported_mip_versions() copies the ranges from the
returned range set to the range set to fill. I believe this makes
_user_get_supported_mip_versions() easier to use than receiving a range
set object and filling it like it's done in C.
The feature is not tested in this patch because the "get supported MIP
versions" method is not used within the library.
Philippe Proulx [Sat, 10 Aug 2019 18:53:32 +0000 (14:53 -0400)]
bt2: add `ComponentDescriptor` class and test
The goal of a `ComponentDescriptor` object is to eventually be used
within an array of descriptors passed to a function which computes an
effective message interchange protocol version with the help of version
support component class methods.
I choose not to wrap the `bt_component_descriptor_set` API as this is
so simple and will be used at a single location.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ifef9b4fb0a7cf0278dbf8bed2d18d0b47934a272
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1873 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
This patch adds the bt_get_greatest_operative_mip_version() and
bt_get_maximal_mip_version() functions.
The bt_get_greatest_operative_mip_version() accepts a set of component
descriptors and returns, on success, the (greatest) operative message
interchange protocol (MIP) version for all those descriptors.
bt_get_greatest_operative_mip_version() can fail if any component class's "get
supported MIP versions" fails. It can also return
`BT_GET_OPERATIVE_MIP_VERSION_STATUS_NO_MATCH` if any component
descriptor does not support MIP version 0, the only MIP version
currently supported by the the library.
bt_get_maximal_mip_version() returns the maximal MIP version supported
by the library (currently 0).
The purpose of both functions is to be used eventually to create a graph
of which all the components and the library itself operate using a
specific MIP. You can use bt_get_greatest_operative_mip_version() to find the
greatest compatible MIP version to be used by that set of component
descriptors, or you can use bt_get_maximal_mip_version() to get the
greatest MIP version possible for that library.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: If3875b3d76ddca2b4d58a18a829394eadb3bcd39
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1872 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sat, 10 Aug 2019 19:18:17 +0000 (15:18 -0400)]
lib: add "get supported MIP versions" method support
This patch adds a new optional method to component classes: get
supported message interchange protocol (MIP) versions.
As of this patch, you can set the "get supported MIP versions" method of
a component class, but it's not used.
The "message interchange protocol" term is very long so I chose to use
the acronym "mip" in the API. The API documentation will make this more
clear.
The method is considered a "class method"; no component exists yet when
calling it (like the query method). The method receives the component
class, the initialization parameters, the initalization method custom
data, and an existing, empty unsigned integer range set. The method's
purpose is to fill this integer range set with all the MIP versions it
supports depending on the initialization configuration. This makes it
possible to support specific MIP versions based on an input path or URI,
for example.
It is a postcondition that the method adds at least one MIP version to
the unsigned integer range set.
The "get supported MIP versions" method is optional: not implementing it
corresponds to adding [0, 0] to the unsigned integer range set. This
makes it possible to implement a component class of which the instance
operates according to the MIP protocol of Babeltrace 2.0.
The "get supported MIP versions" method can fail, but it cannot return
a "try again" status.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib26ec9e90b47a3d3e51cc56465a264de9d02b97c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1870 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
The motivation is to eventually be able to get an effective/compatible
message interchange protocol version number from such a set.
As of this patch, the API is available, but it's not used anywhere.
A component descriptor set is a shared object.
You add a component descriptor to a component descriptor set with
bt_component_descriptor_set_add_descriptor(). Internally, the descriptor
gets appended to one of the source, filter, or sink descriptor array to
eventually have bt_component_descriptor_get_*_descriptor_count() and
bt_component_descriptor_set_borrow_*_descriptor_by_index_const()
functions if needed.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I337d4c596bd988b20849700daf9747a3f188450d
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1868 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Mon, 12 Aug 2019 19:46:05 +0000 (15:46 -0400)]
bt2: py_plugin.py: cache `_PluginInfo` objects
This patch makes _try_load_plugin_module() cache the `_PluginInfo`
objects it creates. The cache, `_plugin_infos`, maps a Python plugin
absolute path to a `_PluginInfo` object.
This avoids loading the Python module twice, which can create problems,
for example destroying component classes earlier than expected when the
new module replaces the old one in `sys.modules`.
Simon Marchi [Mon, 12 Aug 2019 18:37:58 +0000 (14:37 -0400)]
bt2: raise an exception if an AutoSourceComponentSpec produces no component
We don't do anything special at the moment if an AutoSourceComponentSpec
passed to TraceCollectionMessageIterator produces no component. The
created graph will have no source component and the message iterator
will produce no message:
In [5]: list(bt2.TraceCollectionMessageIterator('/yomadame'))
08-12 14:43:03.938 20284 20284 W CLI-CFG-SRC-AUTO-DISC auto_discover_source_components@autodisc.c:755 No trace was found based on input `/yomadame`.
Out[5]: []
This patch changes the behavior to be a bit more strict. If any
AutoSourceComponentSpec passed to TraceCollectionMessageIterator ends up
producing no component, an exception is raised. In the following example, the
directory `/home/smarchi/lttng-traces` does contain some valid traces, and
therefore produces some components, whereas the string `/yomadame` does not
produce any.
In [2]: bt2.TraceCollectionMessageIterator(['/home/smarchi/lttng-traces', '/yomadame'])
08-12 14:45:06.433 24428 24428 W CLI-CFG-SRC-AUTO-DISC auto_discover_source_components@autodisc.c:755 No trace was found based on input `/yomadame`.
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-2-107461e1b36b> in <module>
----> 1 bt2.TraceCollectionMessageIterator(['/home/smarchi/lttng-traces', '/yomadame'])
~/build/babeltrace/src/bindings/python/bt2/build/build_lib/bt2/trace_collection_message_iterator.py in _auto_discover_source_component_specs(auto_source_comp_specs, plugin_set)
194
195 msg = 'Some auto source component specs did not produce any component: ' + ', '.join(unused_inputs)
--> 196 raise RuntimeError(msg)
197
198 return comp_specs
RuntimeError: Some auto source component specs did not produce any component: /yomadame
Change-Id: I6c6df9fad18915e294559948812a8213596affdf Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1885 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 12 Aug 2019 16:25:59 +0000 (12:25 -0400)]
tests: use os.pathsep when appending to BABELTRACE_PLUGIN_PATH
On Windows, we expect BABELTRACE_PLUGIN_PATH entries to be separated
with ';', not ':' (like PATH). Python conveniently provides an
OS-dependent definition for this.
Change-Id: Ie53af04e933258963b8495c72e7607a623e83ddb Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1883 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Sun, 11 Aug 2019 15:33:40 +0000 (11:33 -0400)]
test_plugin.py: do not search in user/system directories for tests
In `test_plugin.py`, make bt2.find_plugin() not search in user and
system directories so that it needs to find the specific plugin in the
test's search path (given by `BABELTRACE_PLUGIN_PATH`) or fail.
Simon Marchi [Sun, 11 Aug 2019 02:31:41 +0000 (22:31 -0400)]
Fix: bt2: replace bt2.CreationError instances with bt2._MemoryError
Commit
4acc866e8298 ("bt2: rename CreationError to MemoryError, handle it in and out of Python bindings")
removed bt2.CreationError in favor of bt2.MemoryError (now
bt2._MemoryError). However, some usages of bt2.CreationError were
introduced afterwards, probably by patches that were in the pipeline.
Replace them with bt2._MemoryError.
Change-Id: Id3cb6542e507b1e41c165ca61df21069d72fb44f Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1867 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 5 Aug 2019 18:45:38 +0000 (14:45 -0400)]
bt2: add auto source discovery support to TraceCollectionMessageIterator
This patch makes TraceCollectionMessageIterator capable of automatically
detecting source components from given input strings, similar to how the
command line interface does.
A new type AutoSourceComponentSpec is introduced. The user can
instantiate this type, passing a mandatory input string (equivalent to a
non-option argument on the CLI). The user can then pass instances of
AutoSourceComponentSpec in the source_component_specs list when creating
a TraceCollectionMessageIterator. In
TraceCollectionMessageIterator.__init_, we run the automatic source
algorithm on all inputs passed through AutoSourceComponentSpec
objects. We create ComponentSpec from the results of the auto discovery
and append them to the source component spec list. The rest of the
TraceCollectionMessageIterator then works as before.
The user can attach params and log levels to AutoSourceComponentSpec
inputs. The semantic for those is the same as for the CLI. There is
also an `obj` parameter, allowing to pass an arbitrary Python object.
The semantic for this one is the same as the log level: if an
auto-discovered component comes from multiple inputs, it will receive
the obj of the last input that contributed to getting it instantiated
that has a non-None `obj`.
For convenience, some shorthands when creating a
TraceCollectionMessageIterator are equivalent to using an
AutoSourceComponentSpec. For example, these three forms are equivalent:
New test cases are added to test the new feature. They are based on
the corresponding CLI tests, in that they test equivalent scenarios
(same inputs, expecting the same results).
In order for TraceCollectionMessageIterator to find the test plugin
(both bt_plugin_test.py files), the only way I found was to amend
BABELTRACE_PLUGIN_PATH for the duration of the test.
Change-Id: I0e1100d850c920723861609cfa14707f8c669892 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1826 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Mon, 5 Aug 2019 15:05:08 +0000 (11:05 -0400)]
Move autodisc to its own convenience library
Since we'll want to make TraceCollectionMessageIterator have an
automatic source discovery feature, like the CLI has, move the auto
discovery code to its own library, which doesn't have any dependency on
the CLI.
To avoid dependencies on the CLI, here are the changes done to the auto
discovery code:
- To avoid depending on cli_query, use a simplified version,
simple_query, included in the auto discovery code. It doesn't handle
retrying if the status is TRY_AGAIN, as it is not very likely that a
babeltrace2.support-info query implementation will need to do that, as
we want them to be very fast (we can always revisit it in the future).
- Avoid using BT_CLI_LOGE_APPEND_CAUSE, replace with the new
BT_AUTODISC_LOGE_AND_APPEND.
- Don't use require_loaded_plugins, get_loaded_plugins_count and
borrow_loaded_plugin, as those are CLI-specific. Instead, the caller of
auto_discover_source_components must provide an array of plugins.
- plugin_restrict, used to filter down to a single plugin by name, is
removed. Instead, it is the caller's responsibility to pass a single
plugin to `plugins` if it wants to restrict the search to a single
plugin.
A side effect of moving the code is that a warning is now printed by
default when no input is found from non-option argument. I think this
is desirable to have this warning printed, so I have opted to update the
test case to expect it.
Change-Id: Id4009976430126d926eac46ff044365a6b2bc006 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1825 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 9 Aug 2019 21:17:35 +0000 (17:17 -0400)]
tests: make auto-source-discovery-{log_level,params} tests use sink.text.details
For the same rationale as the previous patch, change how the test
component classes for test_auto_source_discovery_params and
test_auto_source_discovery_log_level report what they receive from a
print to stdout to stream name.
Change-Id: I62405ccd1fbdbe708fbec5dacc52894d4060dfb0 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1864 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Fri, 9 Aug 2019 20:08:37 +0000 (16:08 -0400)]
tests: make auto-source-discovery-grouping test use sink.text.details
This patch changes the way that test component classes for the auto
source discovery grouping CLI test reports the inputs passed to each
instantiated component.
Currently, they print to stdout the input names
in the components' __init__. That is then check by the test script
(test_auto_source_discovery_grouping). The
TraceCollectionMessageIterator class in the Python bindings will soon
have the capability to automatically discover source components.
However, it's not practical to use the same test method in Python.
To facilitate this, make the test component classes report the inputs
they receive by sending a stream beginning message, where the stream
name contains the input names. The eventual Python test will be able to
inspect the stream name to validate that the right inputs were passed to
each component.
Since the information is now passed in messages, the
test_auto_source_discovery_grouping test now uses the details sink.
Change-Id: Ie5c12e390f5b68fb50a6d18c53463860fb7a1c99 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1863 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Thu, 8 Aug 2019 17:58:47 +0000 (13:58 -0400)]
tests: print executed CLI command line in bt_cli
When debugging a test, it is often useful to have the complete
CLI command line executed, so we can copy paste it and reproduce
the failure by hand.
This patch makes bt_cli echo the executed CLI command line to
stderr, such that it will show up when running one test by hand and in
the test logs when running "make check".
This allows simplifying bt_diff: we no longer have to pass the
CLI arguments to have them included in the error message, since
the full CLI command line will typically be printed just above.
Change-Id: I64f8c80f648d06319efe4e7544447183ba8069cc Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1839 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Thu, 8 Aug 2019 15:09:11 +0000 (11:09 -0400)]
tests: add bt_cli util function
Add a function that simply runs the CLI, redirecting stdout and
stderr to the specified files. This will allow more flexible tests than
the existing "diff" function.
Change-Id: I8319c4a74a0baa3b40afb871bfb0605ac81c3270 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1837 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Fri, 9 Aug 2019 20:30:09 +0000 (16:30 -0400)]
Fix: muxer: check for MUXER_MSG_ITER_CLOCK_CLASS_EXPECTATION_NONE in validate_new_stream_clock_class
There is a problem currently when trying to send multiple streams that
don't have a clock class (which is a supported use case) to a muxer
instance.
The first time we enter validate_new_stream_clock_class without a clock
class, we set the expectation to
MUXER_MSG_ITER_CLOCK_CLASS_EXPECTATION_NONE. The second time we enter
without a clock class, we wrongfully go to the error case. We are
missing a check for MUXER_MSG_ITER_CLOCK_CLASS_EXPECTATION_NONE, which
is the expected and valid case. This patch adds it.
Also, the error message is erroneous. If we are in that situation, we
expect a stream class _without_ a clock class, but are met with a stream
class _with_ a clock class. Fix that at the same time.
Change-Id: Iea692578498ea87a33ecba5d2fd54b2980056cd0 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1862
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 9 Aug 2019 18:57:00 +0000 (14:57 -0400)]
Fix: translate-trace-ir-to-ctf-ir.c: dereference after `NULL` check
We only need to call must_protect_variant_option_name() when the tag
field class is not created by the component (`fc->tag_is_before`).
Furthermore, the local `must_protect` variable is not used, so the
corresponding must_protect_variant_option_name() parameter is not
either. They are both removed. Because the
must_protect_variant_option_name() function actually sets the name of
the option to use (protecting it or not), it's renamed to
maybe_protect_variant_option_name().
Found by Coverity Scan.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ieccc0bcddc5570f473d4303f7cc470a56af65a9e
Fix: src.ctf.lttng-live: omitting stream end on stream hang up
Issue
=====
When receiving a LTTNG_VIEWER_INDEX_HUP request status, a
`src.ctf.lttng-live` component quickly removes the associated stream
iterator and move on to the next request without sending the stream end
message to properly close the stream. This breaks the guarantee that
stream end messages are always present.
Solution
========
Whenever we receive an HUP status from the server, we trigger the
`bt_msg_iter` code to hit an BT_MSG_ITER_MEDIUM_STATUS_EOF so it
generates the stream end message that closes the stream.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: I89924ee95b35ca62c103651ad44c9eaf71f6df53
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1840 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Fri, 9 Aug 2019 13:44:51 +0000 (09:44 -0400)]
Fix: muxer.c: compare_events(): initialize `ret` to 0
GCC complains when this `ret` is not initialized:
muxer.c: In function ‘compare_events’:
muxer.c:993:9: error: ‘ret’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
return ret;
It reaches `return ret` with an uninitialized `ret` when all the tests
fail to find a difference (which can happen).
src.ctf.lttng-live fix: remove overly strict check for session name
The live component checks that the path of a stream contains a
session's name. While this check works when interacting with pre-2.11
peers, there is no reason for a session's name to necessarily be in a
stream's path.
The LTTng relay daemon, as of 2.11, now expresses its path relative to
a session's output path, the session's name no longer appears in a
stream's path.
There are no comments explaining the reason for this check and it is
not present in babeltrace 1.5.x. Hence, it appears safe to remove it.
flt.utils.muxer: deterministically order messages of same timestamps
Issue
=====
The ordering of messages with the exact same timestamp is runtime
dependent. It is causing flakiness in tests using a `sink.text.details`
sink component where such differences in ordering is checked.
Note: It's common to have messages with the same timestamps because that
messages with no clock snapshot are assumed to happen at the same time
that of the previous message.
Solution
========
We need to order messages deterministically even when timestamps are the
same. This commit adds functions to order, in a predictable manner,
messages that have the same timestamp (or no timestamp at all) so that
they are sorted in the same way every time a trace is read.
With this commit:
* We first try to sort the messages by their trace name, stream class
id, or stream id,
* If not possible, we check if the messages have different types and if
they do, we sort them using the following scheme:
SB < PB < EV < DE < MI < PE < DP < SE
* If they are of the same type, we sort them comparing their properties.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Change-Id: Id6fc1fe8b19d02ec1804e54255a73c64820d1e13
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1719 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Fix: extra '%' causes babeltrace2 to abort() in logging code
An extra '%' in a TRACE logging statement causes
bt_common_custom_vsnprintf() to interpret '!' as a conversion
specifier. This causes handle_conversion_specifier_bt() to invoke
abort().
Simon Marchi [Wed, 7 Aug 2019 03:48:44 +0000 (23:48 -0400)]
Fix: bt2: use unsigned iteration variable
This fixes the following compiler diagnostic (gcc 9.1.0):
bt2/native_bt.c: In function ‘_wrap_field_class_enumeration_unsigned_get_mapping_labels_for_value’:
bt2/native_bt.c:9387:25: error: comparison of integer expressions of different signedness: ‘int’ and ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
9387 | for (int i = 0; i < *arg4; i++) {
| ^
Change-Id: I543c61d64c0cf7b42cb242bdbb7b71cbf67dbe48 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1834 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Tue, 6 Aug 2019 16:49:54 +0000 (12:49 -0400)]
Fix: `ctf` plugin: msg-iter.c: do not switch packet twice
Issue
=====
In read_packet_header_begin_state(), bt_msg_iter_switch_packet() is
called systematically at the beginning of the state. However,
buf_ensure_available_bits() can fail below (the medium can return
`BT_MSG_ITER_MEDIUM_STATUS_AGAIN`), and read_packet_header_begin_state()
will be called again next time, calling bt_msg_iter_switch_packet()
twice for the same packet.
One of the problems of calling bt_msg_iter_switch_packet() twice is
that, the first time, the current snapshots are copied to the previous
snapshots and the current snapshots are reset; the second time, the
current (reset) snapshots are copied to the previous snapshots. This
shatters the whole snapshot states. Because the medium installed by
`src.ctf.lttng-live` can return `BT_MSG_ITER_MEDIUM_STATUS_AGAIN`, all
the messages that depend on the previous snapshots, like the discarded
events/packets messages, are wrong.
Solution
========
In `msg-iter.c`, add a new `STATE_SWITCH_PACKET` state which is
dedicated to doing what bt_msg_iter_switch_packet() used to do. Once it
completes, the next state is `STATE_DSCOPE_TRACE_PACKET_HEADER_BEGIN`.
read_packet_header_begin_state() does not switch packets itself now (the
`STATE_SWITCH_PACKET` state already occured at this point), so it can
safely occur twice.
Known drawbacks
===============
There's one more state to handle per packet, but this have a significant
performance hit.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com> Reported-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I24dd2482762c61e339ab0310fddee6c9aa69d438
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1833 Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Tue, 6 Aug 2019 16:47:26 +0000 (12:47 -0400)]
src.ctf.lttng-live: `live_viewer_connection`: make `obj` first member
This fixes a leak. The `bt_object` member must always be the first
because the internal API casts any `void *` parameter to `bt_object *`.
The object API was not getting the correct reference count here.
Philippe Proulx [Tue, 6 Aug 2019 00:31:35 +0000 (20:31 -0400)]
lib, bt2: make query method receive custom data
Just like a component class initialization method can receive custom
user data (`init_method_data`) along with generic parameters, this patch
makes this possible for a query operation.
Library changes
===============
On the library side, this patch introduces the new
bt_query_executor_create_with_method_data() function which is like
bt_query_executor_create(), but accepts a `void *` user data parameter.
Internally, bt_query_executor_create() calls
bt_query_executor_create_with_method_data() with `NULL` as the
`method_data` parameter.
The component class query method type is changed to:
The component class is guaranteed, for a given query executor, to always
being passed the same `method_data` value to its query method.
Python bindings changes
=======================
QueryExecutor.__init__() accepts a new, optional `method_obj` parameter
which defaults to `None`.
`None` gets translated to `NULL` as the `method_data` parameter, and
vice versa when a Python query method is called from the native part.
QueryExecutor.__init__() validates that you can only pass a Python
method object when the component class you query is a Python component
class.
Because you build the query executor and then make a query operation in
two steps, a Python reference to the method object must exist as long as
the query executor exists. This patch makes it reside within the Python
query executor wrapper (`_method_obj` attribute) as there's no way
currently to lose the Python wrapper and retrieve it through a library
call. If this becomes possible in the future, then we can introduce
query executor destruction listeners and add one from the Python
bindings to put the `PyObject *` reference when the query executor is
destroyed. A new test checks this
(test_query_with_method_obj_del_ref()), deleting the test's reference
between the query executor's construction and the actual query
operation. I tried without making the query executor keep a strong
reference and the test causes a segmentation fault, as expected, which
shows that the test is valuable.
Philippe Proulx [Mon, 5 Aug 2019 22:01:09 +0000 (18:01 -0400)]
Add bt_graph_add_simple_sink_component() tests
As of this patch, the tests are basic and only check that the statuses
returned by the user functions are correctly translated and returned by
bt_graph_run_once(). The user initialization function status is not
returned by bt_graph_add_simple_sink_component() because the
initialization function is called within the sink component's "graph is
configured" method.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Id8ccfd7df4e4a8f0a39af386ed4ad13fe657f86a
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1830 Reviewed-by: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Mon, 5 Aug 2019 21:57:27 +0000 (17:57 -0400)]
Fix: src/lib/graph/graph.h: do not override `comp_status` value
This made, for example, bt_graph_run() return
`BT_GRAPH_RUN_STATUS_ERROR` when the sink component's "graph is
configured" method returned
`BT_COMPONENT_CLASS_SINK_GRAPH_IS_CONFIGURED_METHOD_STATUS_MEMORY_ERROR`,
therefore not percolating the correct status.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ic89d9315f8bc1c3226a14955c9e6419462d5e588
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1829 Reviewed-by: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Philippe Proulx [Mon, 5 Aug 2019 20:15:32 +0000 (16:15 -0400)]
lib: add bt_graph_add_simple_sink_component()
This patch adds bt_graph_add_simple_sink_component(), an easy way to add
a simple sink component which has a single message iterator iterating a
single input port named `in` and which calls user-provided functions at
specific locations.
This makes it possible to create a sink component without having to:
* Create a sink component class with initialization, "graph is
configured", "consume", and finalization methods.
* Create an input port in the component class's initialization method.
* Create an input port message iterator in the component class's "graph
is configured" method.
* Put the input port message iterator's reference in the component
class's finalization method.
The goal of this new function is to make it easy to get messages at the
sink endpoint of a graph, just like we used to do with the output port
message iterator concept (but the graph model is honored now). The user
must still call bt_graph_run() or bt_graph_run_once() to make her
consume function (see details below) called: the added simple sink
component is not special in any way.
bt_graph_add_simple_sink_component() receives three function pointers
(and custom user data):
Initialize (optional):
Called after the simple sink component creates the input port
message iterator in the "graph is configured" method.
The user function receives the message iterator to perform any
initial task.
Consume:
Called for each "consume" method call of the simple sink component.
The user function receives the message iterator and can get the next
messages with bt_self_component_port_input_message_iterator_next()
as usual.
Finalize (optional):
Called when the simple sink component is finalized.
The message iterator is not available at this point.
I'm not wrapping this one in Python because it's so easy to replicate
with our bindings:
class _SimpleSink:
def __init__(self, params, consume_cb):
self._consume_cb = consume_cb
self._add_input_port('in')
Philippe Proulx [Sun, 4 Aug 2019 04:24:06 +0000 (00:24 -0400)]
cli, tests: rename "leftover" terms to "non-option"
"Leftover" is a popt term, and we don't use popt anymore. Arguments
which are not options are not leftover anymore: they are treated within
the same loop as option arguments, and their position relative to option
arguments are important, so we simply call them "non-option arguments".
Note that "non-option" is also a term that getopt(1) and getopt(3) use.
Philippe Proulx [Sun, 4 Aug 2019 14:07:18 +0000 (10:07 -0400)]
test_try_again_many_times(): use three times `None`'s ref count
100,000 iterations was arbitrary anyway, so let's just depend on the
initial reference count of `None` and iterate three times that since
this is the object we want to avoid destroy.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I3d587c730b4587d5381d07541d0d86ccff344858
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1822 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sun, 4 Aug 2019 14:04:03 +0000 (10:04 -0400)]
lib: remove output port message iterator
The output port message iterator concept was not a good idea in the
beginning: it breaks the graph model, making it possible to iterate a
disconnected output port (which is weird from the component's
perspective), blocking the graph (user cannot call bt_graph_run()), and
forcing the graph not to contain any sink component. This looks and
feels like a hack.
For the C part, a subsequent patch should implement an easy way to add a
simple sink component to a graph based on a simple callback and custom
user data instead of going through the inconvenience of creating a sink
component class, setting the methods manually, creating an input port
message iterator once the graph is configured, etc.
For the Python part, we'll focus on `TraceCollectionMessageIterator` to
replace `_OutputPortMessageIterator`. `TraceCollectionMessageIterator`
should cover most of the use cases and is easier to use: you don't need
to set up your graph, add your own `flt.utils.muxer`, etc.
For more advanced use cases in Python, it's always possible to create a
"proxy sink component", just like `TraceCollectionMessageIterator` does
internally, to get full control on the input port message iterator.
To adapt the current tests, `TestOutputPortMessageIterator` in
`utils.py` can be used like an output port message iterator. Such an
iterator cannot seek however, so `test_message_iterator.py` needed
special treatments to make the eventual input port message iterator
seek.
Philippe Proulx [Sun, 4 Aug 2019 05:13:15 +0000 (01:13 -0400)]
bt2: make `TraceCollectionMessageIterator` not use an output port msg iter
Because there's a plan to drop the output port message iterator concept
altogether, make `TraceCollectionMessageIterator` not use any output
port message iterator.
Instead, a `TraceCollectionMessageIterator` instance adds a proxy sink
component (`_TraceCollectionMessageIteratorProxySink`) to its graph,
connecting it to the last filter component in the chain, and sharing
with it a list having a single item.
When the sink consumes a message from its upstream message iterator, it
places it in the shared list as the first item.
TraceCollectionMessageIterator.__next__() is changed so that it calls
Graph.run_once() to make the proxy sink consume, and then reads the
consumed message from the shared list.
Philippe Proulx [Sun, 4 Aug 2019 05:11:03 +0000 (01:11 -0400)]
bt2: wrap bt_graph_run_once() (Graph.run_once())
As opposed to Graph.run() which simply returns `None` when it's finished
running, Graph.run_once() needs a way to indicate that the whole graph
is finished. In that case, the method raises `bt2.Stop`. Otherwise,
Graph.run_once() returns `None`.
While bt_graph_run() makes the graph run until the end,
bt_graph_run_once() makes it run a single time, that is, a single sink's
(next in the queue) "consume" operation.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I65dc06c93425d5b5aa1f9e31edf3e22bbeaf77f0
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1818 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sat, 3 Aug 2019 18:36:42 +0000 (14:36 -0400)]
bt2: pass custom Python object to Python component's __init__()
Just like you can pass custom data (`void *`) to the initialization
function of a component class written in C with the
bt_graph_add_*_component_with_init_method_data() functions, this patch
makes it possible to pass any Python object to the __init__() method of
a component class written in Python with the Graph.add_component()
method.
This patch installs a mechanism to share Python data between a Python
graph user and the methods of a Python component without relying on
`nonlocal`, global variables, or other such hacks. This data can be as
simple as an integer and as complex as a database connection, for
example.
The __init__() method of a Python component used to look like:
def __init__(self, params):
...
It's now:
def __init__(self, params, obj):
...
When you pass any Python object to Graph.add_component() as its `obj`
parameter, the Python component's __init__() method eventually receives
it.
Graph.add_component() ensures that the component class to instantiate is
a Python component class if `obj` is not `None`.
Internally, `None` gets converted to `NULL` as the `init_method_data`
parameter of the bt_graph_add_*_component_with_init_method_data()
functions, and then `NULL` gets converted back to `Py_None` in
component_class_init().
Now there is the risk that you call
bt_graph_add_*_component_with_init_method_data() in C with a Python
component class and pass a non-`NULL`, non-`PyObject *`
`init_method_data` parameter. However I consider an insignificant
drawback as you're not supposed to use the `init_method_data` with a
component class you don't know.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib879ece9e423b3495b9449ca73674082020865c5
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1815 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
Philippe Proulx [Sat, 3 Aug 2019 18:29:27 +0000 (14:29 -0400)]
bt2: remove BT CC entry from global HT in _UserComponentType.__del__()
The global `bt_cc_ptr_to_py_cls` hash table maps BT component class
pointers to Python component classes (`PyObject *`) for component
classes created in Python. The key and value are weak references.
When the Python side calls native_bt.bt2_component_class_*_create() with
a Python component class, an entry is added to `bt_cc_ptr_to_py_cls` on
success. This works most of the time because all Python classes are
normally destroyed when the interpreter is finalized, but there could be
issues with specific/unusual import patterns.
To avoid potential issues, remove an entry from `bt_cc_ptr_to_py_cls` in
_UserComponentType.__del__(), where a strong BT component class
reference is finally released.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I450a1c6f179f352e758b9e3e5cac8f4711aa3c88
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1816 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Simon Marchi <simon.marchi@efficios.com>
... all source components discovered from `my-traces-1` will have log
level TRACE and all source components discovered from `my-traces-2` will
have log level DEBUG.
It becomes less obvious when components are given inputs coming from
multiple leftovers (because of the auto-discovery grouping feature):
which log level do they receive? For example, if the following line:
leads to these components getting instantiated, with these inputs:
* Source component X with inputs `my-traces-1/x` and `my-traces-2/x`.
* Source component Y with input `my-traces-1/y`
In this case, each component receives (on the `run` command line) the
log level options of all leftovers that contributed to its inputs, in
the same order as they are provided on the command line. The resulting
`run` command line for the example above could therefore look like:
... all source components discovered from `my-traces-1` will receive
`foo=2` and all source components discovered from `my-traces-2` will
receive `bar=3`.
It becomes less obvious when components are given inputs coming from
multiple leftovers (because of the auto-discovery grouping feature):
which parameters do they receive? For example, if the following line:
leads to these components getting instantiated, with these inputs:
* Source component X with inputs `my-traces-1/x` and `my-traces-2/x`.
* Source component Y with input `my-traces-1/y`
In this case, each component receives the parameters of all leftovers
that contributed to its inputs, in the same order as they are provided
on the command line. The resulting `run` command line for the example
above could therefore look like:
resulting in these parameters being passed to the components:
* Source component X receives parameters `foo=4,bar=3`
* Source component Y receives parameters `foo=2,bar=3`
Implementation details
----------------------
The auto discovery mechanism now returns, for each result, which
input from the passed `inputs` array contributed to that result.
This allows us, for the component that we create from a given result, to
get the parameters from the leftovers that have contributed to it.
Change-Id: Ic048e4e137c2e1f93b6da13a62629343500cb75a Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1809 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Philippe Proulx [Fri, 2 Aug 2019 17:43:59 +0000 (13:43 -0400)]
bt2: move common internal functions to their own files
This patch moves C code from `native_bt_component_class.i` to the new
`native_bt_bt2_objects.h` and `native_bt_log_and_append_error.h` files,
namely:
* bt_bt2_init_from_bt2(), which was bt_bt2_cc_init_from_bt2()
* bt_bt2_exit_handler(), which was bt_bt2_cc_exit_handler()
* The common logging and error appending functions.
This is just cleaner as those functions are not strictly related to the
component class interface.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ic9d7fed993b94b45f624e28e4c512b5ccab776bd
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1814 Reviewed-by: Simon Marchi <simon.marchi@efficios.com> Tested-by: jenkins <jenkins@lttng.org>
Philippe Proulx [Fri, 2 Aug 2019 17:25:42 +0000 (13:25 -0400)]
bt2: put SWIG interface file C code in separate files
This patch moves any code in `%{ %}` blocks within SWIG interface files
(`.i`) to their own files. For a SWIG interface file named `file.i`, the
code is moved to `file.i.h`. In `file.i`, there is:
%{
#include "file.i.h"
%}
This helps with text editors which do not always know how to highlight
the code of a `.i` file.
In `Makefile.am`, the `.i.h` files are added to the
`SWIG_INTERFACE_FILES` variable as they can be considered part of the
SWIG interface files.
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I28975c9b3c827e65ba77af9134521ce1b920d740
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1812 Reviewed-by: Simon Marchi <simon.marchi@efficios.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Thu, 1 Aug 2019 14:57:22 +0000 (10:57 -0400)]
tests: reorganize CLI's `convert` tests
Create a `convert` directory under tests/cli, so we can have
multiple separate tests targeting specific features of the convert
command.
Move test_convert_args in there, this is the file containing the things
that are easy to test, comparing the output of --run-args with an
expected output.
Move the auto source discovery test in there too, as it's a feature of
the convert command. Rename it to "auto source discovery grouping",
since that is mostly what it exercises, and we'll want to add tests for
other areas of auto source discovery.
Change-Id: I20e5085d6b41eec322b777f45be1fee87894fe91 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1808 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Mon, 29 Jul 2019 18:42:23 +0000 (14:42 -0400)]
cli: handle leftovers in the same loop as components
[this patch is better viewed with `git show -w`]
Handle leftovers (put them in the leftovers array) at the same time as
we process --component options and things that apply to components
(--params and --log-level). When we handle a leftover, assign the
current_item_type variable, to override the previous current item.
This change makes it so that we prevent processing --params or
--log-level after a leftover. Previously, this command line:
Would apply the `a=2` param to the `src.bon.jour` instance, since it was
the last component declared. This is confusing, however, because of the
some-leftover leftover in between.
With this patch, the `some-leftover` leftover becomes the "currently"
processed item when we reach it. And since it's not possible (for the
moment) to apply --params or --log-level to a leftover, the command line
shown above now result in the error:
No current component of which to set parameters:
a=2
I improved test_convert_args to be able to check the error message of a
bt2 run we expect to fail. This lets us avoid cases where babeltrace
fails for an unexpected reason, but the test still passes.
Change-Id: I0e065c1cd5f32f59292c9a40c6a8077a52d35237 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1806 Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com> Tested-by: jenkins <jenkins@lttng.org>
Simon Marchi [Tue, 30 Jul 2019 04:34:58 +0000 (00:34 -0400)]
cli: remove `run` and `convert` commands' --name option
There are currently two ways of setting a component's name:
- Using the --name option
- Using the NAME: prefix to the --component option
Having two ways of doing the same thing is not really useful here.
Supporting the --name option complicates the code a little bit: we have
to track whether the current component's name has been set, so that when
we start a new --component, we can generate a name if needed.
This patch removes the --name option in favor of always using the NAME:
prefix of --component. This way, as soon as we handle --component, we
know if the user has provided a name or not, and if not, we can generate
one immediatly (applies only in the convert command; in the run command, the
user must provide a name).
Change-Id: Id278e9d110e4ea415f66538ac55e9459e49b1d0e Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1805 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Tue, 30 Jul 2019 01:29:51 +0000 (21:29 -0400)]
cli: remove `convert` command's --path and --url options
It was decided that these two options can be removed. They are
shortcuts for things that can be set using --params.
The --path option, in particular, is not useful as it used to be: the
de-facto standard parameter that sources are going to accept for their
input data is no longer `path` (it is now `inputs`).
Change-Id: I023e9cdaf319d7a9d2951315ce595ce099648391 Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1804 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Sat, 27 Jul 2019 05:10:16 +0000 (01:10 -0400)]
Remove popt from project's dependencies
All of the argument parsing having been moved to use the internal argpar
library, we can now stop linking with popt. And since it was the last
use of popt in the repo, remove anything related to it.
Change-Id: Id2aee4869780e586833d6b6646e12e19c6d78f6a Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1795 Tested-by: jenkins <jenkins@lttng.org> Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Simon Marchi [Mon, 29 Jul 2019 15:42:58 +0000 (11:42 -0400)]
cli: remove babeltrace2-log
babeltrace-log (now renamed to babeltrace2-log) is a legacy tool
provided by Babeltrace 1 used to transform `dmesg` output to CTF. The
version currently provided by Babeltrace 2 simply runs babeltrace2 with
a pre-defined graph topology. It does nothing that a user couldn't do
on the command line.
projects / babeltrace.git / log
