Snapshot operation on a non-stopped stream should use a "final" flush to
ensure empty packets are flushed, so we gather timestamps at the moment
where the snapshot is taken. This is important for streams that have a
low amount of activity.
In the following scenario:
- create, enable events (kernel),
- start
- ...
- stop (await for data_pending to complete)
- destroy
- rm the trace directory
We would expect that the "rm" operation would not conflict with the
consumer daemon trying to output data into the trace files, since the
"stop" operation ensured that there was no data_pending.
However, the "destroy" operation currently generates an extra packet
after the data_pending check. This causes the consumer daemon to try to
perform trace file rotation concurrently with the trace directory
removal in the scenario above, which triggers errors. The main reason
why this empty packet is generated by "destroy" is to deal with trace
start/stop scenario which would otherwise generate a completely empty
stream.
Therefore, introduce the concept of a "quiescent stream". It is
initialized at false on stream creation (first packet is empty). When
tracing is started, it is set to false (for cases of start/stop/start).
When tracing is stopped, if the stream is not quiescent, perform a
"final" flush (which will generate an empty packet if the current packet
was empty), and set quiescent to true. On "destroy" stream: if the
stream is not quiescent, perform a "final" flush, and set the quiescent
state to true.
Unlike the non-compat version, the compat ioctl lttng ABI code for the
ring buffer flush operation does not invoke
lttng_metadata_output_channel before calling the ring buffer operation.
This could lead to incomplete metadata on 64-bit kernels running with
32-bit lttng userland.
There is also a discrepancy between the non-compat and compat code: the
GET_METADATA_VERSION operation is performed before calling the ring
buffer code. Ensure both non-compat and compat code are alike.
