+Implicit conditions::
++
+--
+* _ER_ itself is enabled.
++
+A recording event rule is enabled on creation.
++
+Enable a disabled recording event rule with the `enable-event` command.
+
+* The channel to which{nbsp}__ER__ is attached is enabled.
++
+A channel is enabled on creation.
++
+Enable a disabled channel with the man:lttng-enable-channel(1) command.
+
+* The recording session of{nbsp}__ER__ is active (started).
++
+A recording session is inactive (stopped) on creation.
++
+Start an inactive recording session with the man:lttng-start(1) command.
+
+* The process for which LTTng creates{nbsp}__E__ is allowed to record
+ events.
++
+All processes are allowed to record events on recording session
+creation.
++
+Use the man:lttng-track(1) and man:lttng-untrack(1) commands to select
+which processes are allowed to record events based on specific process
+attributes.
+--
+
+The dedicated command-line options of most conditions are optional: if
+you don't specify the option, the associated condition is always
+satisfied.
+
+
+[[inst-point-type-cond]]
+Instrumentation point type condition
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+An event{nbsp}__E__ satisfies the instrumentation point type condition
+of a recording event rule if the instrumentation point from which LTTng
+creates{nbsp}__E__ is:
+
+For the Linux kernel tracing domain (option:--kernel option)::
+ With the option:--tracepoint option or without any other instrumentation point type option:::
+ An LTTng kernel tracepoint, that is, a statically defined point
+ in the source code of the kernel image or of a kernel module
+ with LTTng kernel tracer macros.
++
+As of LTTng{nbsp}{lttng_version}, this is the default instrumentation
+point type of the Linux kernel tracing domain, but this may change in
+the future.
++
+List the available Linux kernel tracepoints with `lttng list --kernel`.
+See man:lttng-list(1) to learn more.
+
+ With the option:--syscall option:::
+ The entry and exit of a Linux kernel system call.
++
+List the available Linux kernel system call instrumentation points with
+`lttng list --kernel --syscall`. See man:lttng-list(1) to learn more.
+
+ With the option:--probe option:::
+ A Linux kprobe, that is, a single probe dynamically placed in
+ the compiled kernel code.
++
+The argument of the option:--probe option is the location of the
+kprobe to insert, either a symbol or a
+memory address, while 'RECORDNAME' is the name of the record
+of{nbsp}__E__ (see the ``<<er-name,Event record name>>'' section below).
++
+The payload of a Linux kprobe event is empty.
+
+ With the option:--userspace-probe option:::
+ A Linux user space probe, that is, a single probe dynamically
+ placed at the entry of a compiled user space application/library
+ function through the kernel.
++
+The argument of the option:--userspace-probe option is the location
+of the user space probe to insert, one of:
++
+--
+* A path and symbol (ELF method).
+* A path, provider name, and probe name (SystemTap User-level Statically
+ Defined Tracing (USDT) method; a DTrace-style marker).
++
+As of LTTng{nbsp}{lttng_version}, LTTng only supports USDT probes which
+are :not: reference-counted.
+--
++
+'RECORDNAME' is the name of the record of{nbsp}__E__ (see the
+``<<er-name,Event record name>>'' section below).
++
+The payload of a Linux user space probe event is empty.
+
+ With the option:--function option:::
+ A Linux kretprobe, that is, two probes dynamically placed at the
+ entry and exit of a function in the compiled kernel code.
++
+The argument of the option:--function option is the location of the
+Linux kretprobe to insert, either a symbol or
+a memory address, while 'RECORDNAME' is the name of the record
+of{nbsp}__E__ (see the ``<<er-name,Event record name>>'' section below).
++
+The payload of a Linux kretprobe event is empty.
+
+For the user space tracing domain (option:--userspace option)::
+ With or without the option:--tracepoint option:::
+ An LTTng user space tracepoint, that is, a statically defined
+ point in the source code of a C/$$C++$$ application/library with
+ LTTng user space tracer macros.
++
+As of LTTng{nbsp}{lttng_version}, this is the default and sole
+instrumentation point type of the user space tracing domain, but this
+may change in the future.
++
+List the available user space tracepoints with `lttng list --userspace`.
+See man:lttng-list(1) to learn more.
+
+For the `java.util.logging` (option:--jul option), Apache log4j (option:--log4j option), and Python (option:--python option) tracing domains::
+ With or without the option:--tracepoint option:::
+ A logging statement.
++
+As of LTTng{nbsp}{lttng_version}, this is the default and sole
+instrumentation point type of the `java.util.logging`, Apache log4j, and
+Python tracing domains, but this may change in the future.
++
+List the available Java and Python loggers with `lttng list --jul`,
+`lttng list --log4j`, and `lttng list --python`. See man:lttng-list(1)
+to learn more.
+
+
+[[event-name-cond]]
+Event name condition
+~~~~~~~~~~~~~~~~~~~~
+An event{nbsp}__E__ satisfies the event name condition of a recording
+event rule{nbsp}__ER__ if the two following statements are true:
+
+* You specify the option:--all option or, depending on the
+ instrumentation type condition (see the
+ ``<<inst-point-type-cond,Instrumentation point type condition>>''
+ section above) of{nbsp}__ER__, 'NAME' matches:
++
+--
+LTTng tracepoint::
+ The full name of the tracepoint from which LTTng creates{nbsp}__E__.
++
+Note that the full name of a user space tracepoint is
+__PROVIDER__++:++__NAME__, where __PROVIDER__ is the tracepoint provider
+name and __NAME__ is the tracepoint name.
+
+Logging statement::
+ The name of the Java or Python logger from which LTTng
+ creates{nbsp}__E__.
+
+Linux system call::
+ The name of the system call, without any `sys_` prefix, from which
+ LTTng creates{nbsp}__E__.
+--
+
+* You don't specify the option:--exclude=__XNAME__[++,++__XNAME__]...
+ option or, depending on the instrumentation type condition
+ of{nbsp}__ER__, none of the 'XNAME' arguments matches the full name of
+ the user space tracepoint from which LTTng creates{nbsp}__E__.
++
+The option:--exclude option is only available with the option:--userspace
+option.
+
+This condition is only meaningful for the LTTng tracepoint, logging
+statement, and Linux system call instrumentation point types: it's
+always satisfied for the other types.
+
+In all cases, 'NAME' and 'XNAME' are globbing patterns: the `*`
+character means ``match anything''. To match a literal `*` character,
+use :escwc:. To match a literal `,` character, use
+:esccomma:.
+
+IMPORTANT: Make sure to **single-quote** 'NAME' and 'XNAME' when they
+contain the `*` character and when you run the `enable-event` command
+from a shell.
+
+With the LTTng tracepoint, logging statement, and Linux system call
+instrumentation point types, the `enable-event` command creates or
+enables one independent recording event rule per 'NAME' argument
+(non-option, comma-separated). With the option:--all option, the
+`enable-event` command creates or enables a single recording event rule.
+
+
+[[inst-point-log-level-cond]]
+Instrumentation point log level condition
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+An event{nbsp}__E__ satisfies the instrumentation point log level
+condition of a recording event rule if either:
+
+* The option:--loglevel and option:--loglevel-only options are
+ missing.
+
+* The log level of the LTTng user space tracepoint or logging statement
+ which creates{nbsp}__E__ is:
+ With the option:--loglevel='LOGLEVEL' option::
+ At least as severe as 'LOGLEVEL'.
+
+ With the option:--loglevel-only='LOGLEVEL' option::
+ Exactly 'LOGLEVEL'.
+
+This condition is only meaningful for the LTTng user space tracepoint
+and logging statement instrumentation point types: it's always satisfied
+for other types.
+
+The available values of 'LOGLEVEL' are, depending on the tracing domain,
+from the most to the least severe:
+
+User space (option:--userspace option)::
++
+* `EMERG` (0)
+* `ALERT` (1)
+* `CRIT` (2)
+* `ERR` (3)
+* `WARNING` (4)
+* `NOTICE` (5)
+* `INFO` (6)
+* `DEBUG_SYSTEM` (7)
+* `DEBUG_PROGRAM` (8)
+* `DEBUG_PROCESS` (9)
+* `DEBUG_MODULE` (10)
+* `DEBUG_UNIT` (11)
+* `DEBUG_FUNCTION` (12)
+* `DEBUG_LINE` (13)
+* `DEBUG` (14)
+
+`java.util.logging` (option:--jul option)::
++
+* `OFF` (`INT32_MAX`)
+* `SEVERE` (1000)
+* `WARNING` (900)
+* `INFO` (800)
+* `CONFIG` (700)
+* `FINE` (500)
+* `FINER` (400)
+* `FINEST` (300)
+* `ALL` (`INT32_MIN`)
+
+Apache log4j (option:--log4j option)::
++
+* `OFF` (`INT32_MAX`)
+* `FATAL` (50000)
+* `ERROR` (40000)
+* `WARN` (30000)
+* `INFO` (20000)
+* `DEBUG` (10000)
+* `TRACE` (5000)
+* `ALL` (`INT32_MIN`)
+
+Python (option:--python option)::
++
+* `CRITICAL` (50)
+* `ERROR` (40)
+* `WARNING` (30)
+* `INFO` (20)
+* `DEBUG` (10)
+* `NOTSET` (0)
+
+
+[[filter-cond]]
+Event payload and context filter condition
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+An event{nbsp}__E__ satisfies the event payload and context filter
+condition of a recording event rule if the option:--filter='EXPR'
+option is missing or if 'EXPR' is _true_.
+
+This condition is only meaningful for the LTTng tracepoint and Linux
+system call instrumentation point types: it's always satisfied for other
+types.
+
+'EXPR' can contain references to the payload fields of{nbsp}__E__ and
+to the current context fields.
+
+IMPORTANT: Make sure to **single-quote** 'EXPR' when you run the
+`enable-event` command from a shell, as filter expressions typically
+include characters having a special meaning for most shells.
+
+The expected syntax of 'EXPR' is similar to the syntax of a
+C{nbsp}language conditional expression (an expression which an `if`
+statement can evaluate), but there are a few differences:
+
+* A _NAME_ expression identifies an event payload field named
+ _NAME_ (a C{nbsp}identifier).
++
+Use the C{nbsp}language dot and square bracket notations to access
+nested structure and array/sequence fields. You can only use a constant,
+positive integer number within square brackets. If the index is out of
+bounds, 'EXPR' is _false_.
++
+The value of an enumeration field is an integer.
++
+When a field expression doesn't exist, 'EXPR' is _false_.
++
+Examples: `my_field`, `target_cpu`, `seq[7]`, `msg.user[1].data[2][17]`.
+
+* A ++$ctx.++__TYPE__ expression identifies the statically-known context
+ field having the type _TYPE_ (a C{nbsp}identifier).
++
+List the available statically-known context field names with the
+man:lttng-add-context(1) command.
++
+When a field expression doesn't exist, 'EXPR' is _false_.
++
+Examples: `$ctx.prio`, `$ctx.preemptible`,
+`$ctx.perf:cpu:stalled-cycles-frontend`.
+
+* A ++$app.++__PROVIDER__++:++__TYPE__ expression identifies the
+ application-specific context field having the type _TYPE_ (a
+ C{nbsp}identifier) from the provider _PROVIDER_ (a C{nbsp}identifier).
++
+When a field expression doesn't exist, 'EXPR' is _false_.
++
+Example: `$app.server:cur_user`.
+
+* Compare strings, either string fields or string literals
+ (double-quoted), with the `==` and `!=` operators.
++
+When comparing to a string literal, the `*` character means ``match
+anything''. To match a literal `*` character, use :escwc:.
++
+Examples: `my_field == "user34"`, `my_field == my_other_field`,
+`my_field == "192.168.*"`.
+
+* The precedence table of the operators which are supported in 'EXPR'
+ is as follows. In this table, the highest precedence is{nbsp}1:
++
+[options="header"]
+|===
+|Precedence |Operator |Description |Associativity
+|1 |`-` |Unary minus |Right-to-left
+|1 |`+` |Unary plus |Right-to-left
+|1 |`!` |Logical NOT |Right-to-left
+|1 |`~` |Bitwise NOT |Right-to-left
+|2 |`<<` |Bitwise left shift |Left-to-right
+|2 |`>>` |Bitwise right shift |Left-to-right
+|3 |`&` |Bitwise AND |Left-to-right
+|4 |`^` |Bitwise XOR |Left-to-right
+|5 |`\|` |Bitwise OR |Left-to-right
+|6 |`<` |Less than |Left-to-right
+|6 |`<=` |Less than or equal to |Left-to-right
+|6 |`>` |Greater than |Left-to-right
+|6 |`>=` |Greater than or equal to |Left-to-right
+|7 |`==` |Equal to |Left-to-right
+|7 |`!=` |Not equal to |Left-to-right
+|8 |`&&` |Logical AND |Left-to-right
+|9 |`\|\|` |Logical OR |Left-to-right
+|===
++
+Parentheses are supported to bypass the default order.
++
+IMPORTANT: Unlike the C{nbsp}language, the bitwise AND and OR operators
+(`&` and `|`) in 'EXPR' take precedence over relational operators (`<`,
+`<=`, `>`, `>=`, `==`, and `!=`). This means the expression `2 & 2 == 2`
+is _true_ while the equivalent C{nbsp}expression is _false_.
++
+The arithmetic operators are :not: supported.
++
+LTTng first casts all integer constants and fields to signed 64-bit
+integers. The representation of negative integers is two's complement.
+This means that, for example, the signed 8-bit integer field 0xff (-1)
+becomes 0xffffffffffffffff (still -1) once casted.
++
+Before a bitwise operator is applied, LTTng casts all its operands to
+unsigned 64-bit integers, and then casts the result back to a signed
+64-bit integer. For the bitwise NOT operator, it's the equivalent of
+this C{nbsp}expression:
++
+[source,c]
+----
+(int64_t) ~((uint64_t) val)