Hi Steven,

I looked through the current trace_marker_raw users and the expected
usage more carefully.

The existing users I found treat trace_marker_raw as a binary channel
and parse the data from raw events or trace_pipe_raw, not from the
formatted trace output. Given that, I do not see a strong requirement
for TRACE_RAW_DATA itself to carry and maintain an exact payload length
just for the text printing path.

So I agree this is not really a technical limitation in the current
implementation, but a requirement question, and the requirement does
not look strong enough here.

I'll drop this series for now and close this task on my side.

Thanks,
Cao Ruichuang


Reply via email to