| 1 | = babeltrace2-intro(7) |
| 2 | :manpagetype: manual page |
| 3 | :revdate: 14 September 2019 |
| 4 | |
| 5 | |
| 6 | == NAME |
| 7 | |
| 8 | babeltrace2-intro - Introduction to Babeltrace 2 |
| 9 | |
| 10 | |
| 11 | == DESCRIPTION |
| 12 | |
| 13 | This manual page is an introduction to the Babeltrace~2 project. |
| 14 | |
| 15 | The <<what-is,``WHAT IS BABELTRACE~2?''>> section describes the |
| 16 | parts of the project and shows the major changes from Babeltrace~1 |
| 17 | to Babeltrace~2 while the <<concepts,``BABELTRACE~2 |
| 18 | CONCEPTS''>> section defines the core concepts of Babeltrace~2. |
| 19 | |
| 20 | The <<graph-repr,``TRACE PROCESSING GRAPH REPRESENTATION''>> section |
| 21 | shows how some <<concepts,concepts>> are visually represented in other |
| 22 | Babeltrace~2 manual pages. |
| 23 | |
| 24 | |
| 25 | [[what-is]] |
| 26 | == WHAT IS BABELTRACE~2? |
| 27 | |
| 28 | Babeltrace~2 is an open-source software project of which the |
| 29 | purpose is to process or convert |
| 30 | https://en.wikipedia.org/wiki/Tracing_(software)[traces]. |
| 31 | |
| 32 | The Babeltrace~2 project includes the following parts: |
| 33 | |
| 34 | [[libbabeltrace2]]Babeltrace~2 library (libbabeltrace2):: |
| 35 | A shared library with a C API. |
| 36 | + |
| 37 | With libbabeltrace2, you can programmatically create <<plugin,plugins>> |
| 38 | and <<comp-cls,component classes>>, build and run <<graph,trace |
| 39 | processing graphs>>, and more (see the <<concepts,``BABELTRACE~2 |
| 40 | CONCEPTS''>> section for more details about those concepts). |
| 41 | + |
| 42 | All the other Babeltrace~2 parts rely on this library. |
| 43 | |
| 44 | [[babeltrace2]]`babeltrace2` command-line program:: |
| 45 | A command-line interface which uses libbabeltrace2 to load plugins, |
| 46 | create a trace processing graph, create <<comp,components>>, connect |
| 47 | their <<port,ports>> correctly, and run the graph. |
| 48 | + |
| 49 | You can also use `babeltrace2` to list the available plugins or to |
| 50 | <<query,query>> an object from a component class. |
| 51 | + |
| 52 | See man:babeltrace2(1). |
| 53 | |
| 54 | [[python-bindings]]Babeltrace~2 Python bindings:: |
| 55 | A Python~3 package (`bt2`) which offers a Pythonic interface of |
| 56 | libbabeltrace2. |
| 57 | + |
| 58 | You can perform the same operations which are available in |
| 59 | libbabeltrace2 with the Python bindings, but more conveniently and with |
| 60 | less code. However, the Python bindings are less performant than |
| 61 | libbabeltrace2. |
| 62 | |
| 63 | Babeltrace~2 project's plugins:: |
| 64 | The Babeltrace~2 <<plugin,plugins>> shipped with the project. |
| 65 | + |
| 66 | Those plugins are not special in that they only rely on libbabeltrace2 |
| 67 | and you don't need them to use libbabeltrace2, man:babeltrace2(1), or |
| 68 | the Python bindings. However, the project's plugins provide many widely |
| 69 | used trace format encoders/decoders as well as common <<graph,trace |
| 70 | processing graph>> utilities. |
| 71 | + |
| 72 | The Babeltrace~2 project's plugins are: |
| 73 | + |
| 74 | -- |
| 75 | `ctf`:: |
| 76 | https://diamon.org/ctf/[Common Trace Format] (CTF) input/output, |
| 77 | including the LTTng live source. |
| 78 | + |
| 79 | See man:babeltrace2-plugin-ctf(7). |
| 80 | |
| 81 | `lttng-utils`:: |
| 82 | Graph utilities specific to https://lttng.org/[LTTng] traces. |
| 83 | + |
| 84 | See man:babeltrace2-plugin-lttng-utils(7). |
| 85 | |
| 86 | `text`:: |
| 87 | Plain text input/output. |
| 88 | + |
| 89 | See man:babeltrace2-plugin-text(7). |
| 90 | |
| 91 | `utils`:: |
| 92 | Common graph utilities (muxer, trimmer, counter, dummy sink). |
| 93 | + |
| 94 | See man:babeltrace2-plugin-utils(7). |
| 95 | -- |
| 96 | |
| 97 | |
| 98 | === Changes since Babeltrace~1 |
| 99 | |
| 100 | This manual page is an introduction to Babeltrace~2, a rewrite of |
| 101 | Babeltrace~1 with a focus on extensibility, flexibility, and |
| 102 | interoperability. |
| 103 | |
| 104 | Babeltrace~1 exists since 2010. |
| 105 | |
| 106 | You can install both projects on the same file system as there are no |
| 107 | file name conflicts. |
| 108 | |
| 109 | The major improvements brought by Babeltrace~2 are: |
| 110 | |
| 111 | General:: |
| 112 | + |
| 113 | -- |
| 114 | * Full <<plugin,plugin>> support: any user can distribute a Babeltrace~2 |
| 115 | plugin and, as long as <<libbabeltrace2,libbabeltrace2>> finds it, any |
| 116 | application linked to libbabeltrace2 can load it and use it. |
| 117 | + |
| 118 | Plugins are not just trace format encoders and decoders: they package |
| 119 | source, filter, and sink <<comp-cls,component classes>> so that you can |
| 120 | connect specialized, reusable <<comp,components>> together in a |
| 121 | <<graph,trace processing graph>> to create a customized trace conversion |
| 122 | or analysis device. |
| 123 | + |
| 124 | This modular strategy is much like how the |
| 125 | https://www.ffmpeg.org/[FFmpeg], |
| 126 | https://gstreamer.freedesktop.org/[GStreamer], and |
| 127 | https://en.wikipedia.org/wiki/DirectShow[DirectShow] projects approach |
| 128 | media stream processing. |
| 129 | |
| 130 | * All the parts of the Babeltrace~2 project run on the major |
| 131 | operating systems, including Windows and macOS. |
| 132 | |
| 133 | * Some <<comp-cls,component classes>>, such as compcls:sink.text.pretty |
| 134 | (similar to the `text` output format of man:babeltrace(1)) and |
| 135 | compcls:sink.text.details, can write color codes to the standard |
| 136 | output when it's connected to a color-enabled terminal. |
| 137 | + |
| 138 | The Babeltrace~2 log, printed to the standard output, can also be |
| 139 | colorized. |
| 140 | -- |
| 141 | |
| 142 | Command-line interface:: |
| 143 | + |
| 144 | -- |
| 145 | * Whereas you can convert traces from one format to another with |
| 146 | Babeltrace~1's CLI tool, man:babeltrace(1), you can also execute a |
| 147 | custom trace manipulation task with man:babeltrace2(1) thanks to the |
| 148 | man:babeltrace2-run(1) command. |
| 149 | |
| 150 | * The man:babeltrace2-convert(1) command features an automatic source |
| 151 | component discovery algorithm to find the best suited components to |
| 152 | create for a given non-option argument (file or directory path, or |
| 153 | custom string like an https://lttng.org[LTTng live] URL). |
| 154 | + |
| 155 | For example: |
| 156 | + |
| 157 | [role="term"] |
| 158 | ---- |
| 159 | $ babeltrace2 /path/to/ctf/trace |
| 160 | ---- |
| 161 | + |
| 162 | [role="term"] |
| 163 | ---- |
| 164 | $ babeltrace2 net://localhost/host/myhost/my-session |
| 165 | ---- |
| 166 | -- |
| 167 | |
| 168 | https://diamon.org/ctf/[CTF] input/output:: |
| 169 | + |
| 170 | -- |
| 171 | * The compcls:source.ctf.fs component class, which is more or less the |
| 172 | equivalent of Babeltrace~1's `ctf` input format, has features |
| 173 | not found in Babeltrace~1: |
| 174 | + |
| 175 | -- |
| 176 | ** The component handles many trace quirks which are the results of |
| 177 | known tracer bugs and corner cases (LTTng-UST, LTTng-modules, and |
| 178 | https://github.com/efficios/barectf[barectf]), making it possible to |
| 179 | decode malformed packets. |
| 180 | |
| 181 | ** The component merges CTF traces sharing the same UUID into a single, |
| 182 | logical trace. |
| 183 | + |
| 184 | This feature supports LTTng~2.11's tracing session rotation trace |
| 185 | chunks. |
| 186 | -- |
| 187 | |
| 188 | * With a compcls:sink.ctf.fs component, you can create CTF traces on |
| 189 | the file system. |
| 190 | + |
| 191 | With man:babeltrace2(1), you can use the `--output-format=ctf` and |
| 192 | manopt:babeltrace2-convert(1):--output options to create an implicit |
| 193 | compcls:sink.ctf.fs component. |
| 194 | + |
| 195 | For example: |
| 196 | + |
| 197 | [role="term"] |
| 198 | ---- |
| 199 | $ babeltrace2 /path/to/input/trace \ |
| 200 | --output-format=ctf --output=trace-dir |
| 201 | ---- |
| 202 | -- |
| 203 | |
| 204 | https://lttng.org[LTTng live] input:: |
| 205 | + |
| 206 | -- |
| 207 | * The man:babeltrace(1) command exits successfully when it cannot find |
| 208 | an LTTng live (`--input-format=lttng-live` option) tracing session. |
| 209 | + |
| 210 | The manparam:source.ctf.lttng-live:session-not-found-action |
| 211 | initialization parameter controls what a compcls:source.ctf.lttng-live |
| 212 | <<msg-iter,message iterator>> does when it cannot find the remote |
| 213 | tracing session. |
| 214 | + |
| 215 | If the action is `end`, the message iterator does like man:babeltrace(1) |
| 216 | and simply ends successfully. |
| 217 | + |
| 218 | If the action is `continue` (the default), the message iterator never |
| 219 | ends: it keeps on trying until the tracing session exists, indeed |
| 220 | subscribing to the session. |
| 221 | -- |
| 222 | |
| 223 | Library:: |
| 224 | + |
| 225 | -- |
| 226 | * <<libbabeltrace2,libbabeltrace2>> shares nothing with libbabeltrace. |
| 227 | + |
| 228 | The Babeltrace~2 library C API has features such as: |
| 229 | + |
| 230 | -- |
| 231 | * A single header file. |
| 232 | * Function precondition and postcondition checking. |
| 233 | * Object-oriented model with shared and unique objects. |
| 234 | * Strict C typing and `const` correctness. |
| 235 | * User-extensible classes. |
| 236 | * Rich, thread-safe error reporting. |
| 237 | * Per-<<comp,component>> and per-subsystem logging levels. |
| 238 | * Trace intermediate representation (IR) objects to make the API |
| 239 | trace-format-agnostic. |
| 240 | * A versioned protocol for message interchange between components to |
| 241 | enable forward and backward compatibility. |
| 242 | -- |
| 243 | |
| 244 | * You can build the library in developer mode to enable an extensive set |
| 245 | of function precondition and postcondition checks. |
| 246 | + |
| 247 | The developer mode can help detect programming errors early when you |
| 248 | develop a Babeltrace~2 <<plugin,plugin>> or an application using |
| 249 | libbabeltrace2. |
| 250 | + |
| 251 | See the project's `README` for build-time requirements and detailed |
| 252 | build instructions. |
| 253 | |
| 254 | -- |
| 255 | |
| 256 | |
| 257 | [[concepts]] |
| 258 | == BABELTRACE~2 CONCEPTS |
| 259 | |
| 260 | This section defines the main concepts of the Babeltrace~2 project. |
| 261 | |
| 262 | These concepts translate into types and functions in |
| 263 | <<libbabeltrace2,libbabeltrace2>> and its <<python-bindings,Python |
| 264 | bindings>>, but also as command-line actions and options in the |
| 265 | <<babeltrace2,`babeltrace2` program>>. The other Babeltrace~2 |
| 266 | manual pages assume that you are familiar with the following |
| 267 | definitions. |
| 268 | |
| 269 | Some Babeltrace~2 concepts are interdependent: it is normal to jump |
| 270 | from one definition to another to understand the big picture. |
| 271 | |
| 272 | [[comp-cls]]Component class:: |
| 273 | A reusable class which you can instantiate as one or more |
| 274 | <<comp,components>> within a <<graph,trace processing graph>>. |
| 275 | + |
| 276 | There are three types of component classes used to create the three |
| 277 | types of components: source, filter, and sink. |
| 278 | + |
| 279 | A component class implements methods, one of which is an initialization |
| 280 | method, or constructor, to create a component. You pass _initialization |
| 281 | parameters_ to this method to customize the created component. For |
| 282 | example, the initialization method of the compcls:source.ctf.fs |
| 283 | component class accepts a mandatory manparam:source.ctf.fs:inputs |
| 284 | parameter which is an array of file system path(s) to the CTF trace(s). |
| 285 | It also accepts an optional manparam:source.ctf.fs:clock-class-offset-ns |
| 286 | parameter which is an offset, in nanoseconds, to add to all the clock |
| 287 | classes (descriptors of stream clocks) found in the traces's metadata. |
| 288 | + |
| 289 | A component class can have a description and a help text. |
| 290 | |
| 291 | [[comp]]Component:: |
| 292 | A node within a <<graph,trace processing graph>>. |
| 293 | + |
| 294 | There are three types of components: |
| 295 | + |
| 296 | -- |
| 297 | Source component:: |
| 298 | An input component which produces <<msg,messages>>. |
| 299 | + |
| 300 | Examples: CTF files input, log file input, LTTng live input, random |
| 301 | event generator. |
| 302 | |
| 303 | Filter component:: |
| 304 | An intermediate component which can transform the messages it |
| 305 | consumes, augment them, sort them, discard them, or create new ones. |
| 306 | + |
| 307 | Examples: filter which removes messages based on an expression, |
| 308 | filter which adds debugging information to selected events, message |
| 309 | muxer, trace trimmer. |
| 310 | |
| 311 | Sink component:: |
| 312 | An output component which consumes messages and usually writes them |
| 313 | to one or more formatted files. |
| 314 | + |
| 315 | Examples: log file output, CTF files output, pretty-printed plain text |
| 316 | output. |
| 317 | -- |
| 318 | + |
| 319 | Components are connected together within a <<graph,trace processing |
| 320 | graph>> through their <<port,ports>>. Source components have output |
| 321 | ports, sink components have input ports, and filter components have |
| 322 | both. |
| 323 | + |
| 324 | A component is the instance of a <<comp-cls,component class>>. The terms |
| 325 | _component_ and _component class instance_ are equivalent. |
| 326 | + |
| 327 | Within a trace processing graph, each component has a unique name. This |
| 328 | is not the name of its component class, but an instance name. If `human` |
| 329 | is a component class name, than `Nancy` and `John` could be component |
| 330 | names. |
| 331 | + |
| 332 | Once a <<graph,graph>> is configured (the first time it runs), you |
| 333 | cannot add components to it for the remaining graph's lifetime. |
| 334 | |
| 335 | [[port]]Port:: |
| 336 | A connection point, on a <<comp,component>>, from which are sent or |
| 337 | where are received <<msg,messages>> when the <<graph,trace |
| 338 | processing graph>> runs. |
| 339 | + |
| 340 | An output port is from where messages are sent. An input port is where |
| 341 | messages are received. Source components have output ports, sink |
| 342 | components have input ports, and filter components have both. |
| 343 | + |
| 344 | You can only connect an output port to a single input port. |
| 345 | + |
| 346 | All ports do not need to be connected. |
| 347 | + |
| 348 | A filter or sink component receiving messages from its input ports |
| 349 | is said to _consume_ messages. |
| 350 | + |
| 351 | The link between an output port and input port is a <<conn,connection>>. |
| 352 | + |
| 353 | Once a <<graph,graph>> is configured (the first time it runs), you |
| 354 | cannot connect ports for the remaining graph's lifetime. |
| 355 | |
| 356 | [[conn]]Connection:: |
| 357 | The link between an output <<port,port>> and an input port through |
| 358 | which <<msg,messages>> flow when a <<graph,trace processing |
| 359 | graph>> runs. |
| 360 | |
| 361 | [[msg-iter]]Message iterator:: |
| 362 | An iterator on an input <<port,port>> of which the returned elements |
| 363 | are <<msg,messages>>. |
| 364 | + |
| 365 | A <<comp,component>> or another message iterator can create many message |
| 366 | iterators on a single input port, before or while the <<graph,trace |
| 367 | processing graph>> runs. |
| 368 | |
| 369 | [[msg]]Message:: |
| 370 | The element of a <<msg-iter,message iterator>>. |
| 371 | + |
| 372 | Messages flow from output <<port,ports>> to input ports. |
| 373 | + |
| 374 | A source <<comp,component>> <<msg-iter,message iterator>> produces |
| 375 | messages, while a sink component consumes them. A filter component |
| 376 | message iterator can both consume and produce messages. |
| 377 | + |
| 378 | The main types of messages are: |
| 379 | + |
| 380 | -- |
| 381 | Event:: |
| 382 | A trace event record within a packet or within a stream. |
| 383 | |
| 384 | Packet beginning:: |
| 385 | The beginning of a packet within a stream. |
| 386 | + |
| 387 | A packet is a conceptual container of events. |
| 388 | |
| 389 | Packet end:: |
| 390 | The end of a packet within a stream. |
| 391 | |
| 392 | Stream beginning:: |
| 393 | The beginning of a stream. |
| 394 | + |
| 395 | A stream is a conceptual container of packets and/or events. |
| 396 | + |
| 397 | Usually, a given source component's output port sends packet and event |
| 398 | messages which belong to a single stream, but it's not required. |
| 399 | |
| 400 | Stream end:: |
| 401 | The end of a stream. |
| 402 | |
| 403 | Discarded events:: |
| 404 | A count of discarded events within a given time interval for a given |
| 405 | stream. |
| 406 | |
| 407 | Discarded packets:: |
| 408 | A count of discarded packets within a given time interval for a |
| 409 | given stream. |
| 410 | -- |
| 411 | |
| 412 | [[graph]]Trace processing graph:: |
| 413 | A https://en.wikipedia.org/wiki/Filter_graph[filter graph] where |
| 414 | nodes are <<comp,components>> and <<msg,messages>> flow from |
| 415 | output <<port,ports>> to input ports. |
| 416 | + |
| 417 | You can build a trace processing graph with |
| 418 | <<libbabeltrace2,libbabeltrace2>>, with the |
| 419 | <<python-bindings,Babeltrace~2 Python bindings>>, or with the |
| 420 | man:babeltrace2-run(1) and man:babeltrace2-convert(1) CLI commands. |
| 421 | + |
| 422 | When a trace processing graph _runs_, the sink components consume |
| 423 | messages from their input ports, making all the graph's |
| 424 | <<msg-iter,message iterators>> work one message at a time to perform the |
| 425 | trace conversion or analysis duty. |
| 426 | |
| 427 | [[plugin]]Plugin:: |
| 428 | A container, or package, of <<comp-cls,component classes>> as a |
| 429 | shared library or Python module. |
| 430 | + |
| 431 | Each component class within a plugin has a type (source, filter, or |
| 432 | sink) and a name. The type and name pair is unique within a given |
| 433 | plugin. |
| 434 | + |
| 435 | <<libbabeltrace2,libbabeltrace2>> can load a plugin (`.so`, `.dll`, or |
| 436 | `.py` file) at run time: the result is a plugin object in which you can |
| 437 | find a specific component class and instantiate it within a |
| 438 | <<graph,trace processing graph>> as a <<comp,component>>. |
| 439 | + |
| 440 | The <<babeltrace2,`babeltrace2` program>> uses the |
| 441 | 'COMP-CLS-TYPE.PLUGIN-NAME.COMP-CLS-NAME' format to identify a specific |
| 442 | component class within a specific plugin. 'COMP-CLS-TYPE' is either |
| 443 | `source` (or `src`), `filter` (or `flt`), or `sink`. |
| 444 | + |
| 445 | You can list the available Babeltrace~2 plugins with the |
| 446 | man:babeltrace2-list-plugins(1) command. |
| 447 | |
| 448 | [[query]]Query:: |
| 449 | An operation with which you can get a named object from a |
| 450 | <<comp-cls,component class>>, possibly with custom query parameters. |
| 451 | + |
| 452 | The plain text metadata stream of a CTF trace and the available LTTng |
| 453 | live sessions of a given LTTng relay daemon are examples of query |
| 454 | objects. |
| 455 | + |
| 456 | You can use <<libbabeltrace2,libbabeltrace2>>, the |
| 457 | <<python-bindings,Babeltrace~2 Python bindings>>, or the |
| 458 | man:babeltrace2-query(1) CLI command to query a component class's |
| 459 | object. |
| 460 | |
| 461 | |
| 462 | [[graph-repr]] |
| 463 | == TRACE PROCESSING GRAPH REPRESENTATION |
| 464 | |
| 465 | In the Babeltrace~2 manual pages, a component is represented with a |
| 466 | box. The box has the <<comp-cls,component class>> type, |
| 467 | <<plugin,plugin>> name, and component class name at the top. Just below, |
| 468 | between square brackets, is its component name within the <<graph,trace |
| 469 | processing graph>>. Each <<port,port>> is represented with an `@` symbol |
| 470 | on the border(s) of the component box with its name inside the box. |
| 471 | Output ports are on the box's right border while input ports are on the |
| 472 | box's left border. |
| 473 | |
| 474 | For example, here's a source component box: |
| 475 | |
| 476 | ---- |
| 477 | +------------+ |
| 478 | | src.ctf.fs | |
| 479 | | [my-src] | |
| 480 | | | |
| 481 | | stream0 @ |
| 482 | | stream1 @ |
| 483 | | stream2 @ |
| 484 | +------------+ |
| 485 | ---- |
| 486 | |
| 487 | This one is an instance of the compcls:source.ctf.fs component class |
| 488 | named `my-src`. It has three output ports named `stream0`, `stream1`, |
| 489 | and `stream2`. |
| 490 | |
| 491 | A trace processing graph is represented with multiple component boxes |
| 492 | connected together. The <<conn,connections>> are arrows from output |
| 493 | ports to input ports. |
| 494 | |
| 495 | For example, here's a simple conversion graph: |
| 496 | |
| 497 | ---- |
| 498 | +------------+ +-----------------+ +------------------+ |
| 499 | | src.ctf.fs | | flt.utils.muxer | | sink.text.pretty | |
| 500 | | [ctf] | | [muxer] | | [text] | |
| 501 | | | | | | | |
| 502 | | stream0 @--->@ in0 out @--->@ in | |
| 503 | | stream1 @--->@ in1 | +------------------+ |
| 504 | | stream2 @--->@ in2 | |
| 505 | +------------+ @ in3 | |
| 506 | +-----------------+ |
| 507 | ---- |
| 508 | |
| 509 | Note that input port `in3` of component `muxer` is not connected in this |
| 510 | example. |
| 511 | |
| 512 | Sometimes, we symbolically represent other resources which are consumed |
| 513 | from or produced by components. In this case, arrows are used, but they |
| 514 | do not go to or from port symbols (`@`), except for messages. For |
| 515 | example, in the graph above, the `ctf` source component consumes a CTF |
| 516 | trace and the `text` sink component prints plain text to the terminal, |
| 517 | so here's a more complete diagram: |
| 518 | |
| 519 | ---- |
| 520 | CTF trace |
| 521 | | |
| 522 | | +------------+ +-----------------+ +------------------+ |
| 523 | | | src.ctf.fs | | flt.utils.muxer | | sink.text.pretty | |
| 524 | '-->| [ctf] | | [muxer] | | [text] | |
| 525 | | | | | | | |
| 526 | | stream0 @--->@ in0 out @--->@ in | |
| 527 | | stream1 @--->@ in1 | +-----+------------+ |
| 528 | | stream2 @--->@ in2 | | |
| 529 | +------------+ @ in3 | '--> Terminal |
| 530 | +-----------------+ |
| 531 | ---- |
| 532 | |
| 533 | Here's another example of a more complex graph which splits a specific |
| 534 | stream using some criteria: |
| 535 | |
| 536 | ---- |
| 537 | +------------+ +-----------------+ +------------------+ |
| 538 | | src.ctf.fs | | flt.utils.muxer | | sink.text.pretty | |
| 539 | | [ctf-in] | | [muxer] | | [text] | |
| 540 | | | | | | | |
| 541 | | stream0 @--->@ in0 out @--->@ in | |
| 542 | | stream1 @--->@ in1 | +------------------+ |
| 543 | | stream2 @-. @ in2 | |
| 544 | +------------+ | +-----------------+ +-------------+ |
| 545 | | | sink.ctf.fs | |
| 546 | | | [ctf-out0] | |
| 547 | | +-------------------+ | | |
| 548 | | | flt.some.splitter | .->@ in | |
| 549 | | | [splitter] | | +-------------+ |
| 550 | | | | | |
| 551 | '->@ in A @-' +-------------+ |
| 552 | | B @-. | sink.ctf.fs | |
| 553 | +-------------------+ | | [ctf-out1] | |
| 554 | | | | |
| 555 | '->@ in | |
| 556 | +-------------+ |
| 557 | ---- |
| 558 | |
| 559 | |
| 560 | include::common-footer.txt[] |
| 561 | |
| 562 | |
| 563 | == SEE ALSO |
| 564 | |
| 565 | man:babeltrace2(1) |