On 26/08/2026 16:36, Leo Yan wrote:
On Fri, Aug 21, 2026 at 10:49:01AM +0100, James Clark wrote:
@@ -453,13 +453,22 @@ static int cs_etm_recording_options(struct auxtrace_record *itr, */ evsel__set_sample_bit(cs_etm_evsel, CPU);
- /*
* Also the case of per-cpu mmaps, need the contextID in order to be notified* when a context switch happened.*/
/** Timestamps are required to interleave samples from different* CPUs.*//* Context IDs are required to associate trace to a process */- } else {
/** Enable context packet timestamps only (no periodic
* timestamps). Even in per-thread mode with a single process we* still need to correlate trace to a specific mmap around* execs, which can be done with just context packet timestamps.Could we use terminology that is aligned with the ETM spec?
"Disable periodic timestamps but generate timestamps for trace synchronization ... to a specific mmap around execs, which can be done with just timestamps of trace synchronization."
Done.
*/evsel__set_config_if_unset(cs_etm_evsel, "timestamp", UINT64_MAX);It seems this will eventually convert UINT64_MAX to 0xf for the timestamp bit field. Why not use 0xf directly to avoid confusion?
Then it wouldn't support the size of the field changing. I thought that was the point of the kernel publishing the fields dynamically. Hard coding widths and positions in userspace only caused issues in the past.
I don't think "...MAX" is confusing for what the intention is, but maybe a comment would be better than hard coding it?
} /*
-- 2.43.0