On Fri, May 20, 2022 at 4:08 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > >> + be32 max_apicid; >> be32 page_size; >> u64 trace_id; >> char tsync_proto_name[TRACECMD_TSYNC_PNAME_LENGTH]; > >Unfortunately, the above will break the protocol for released instances of >trace-cmd that is already out there. One requirement I have is that if two >instances of trace-cmd use to work (on host and guest) that if you upgrade >one of them, what use to work still does. > >We need to figure out another way to handle this :-/ > Ahh ok, understood.. I think we should also think about versioning the guest/host protocols because this kind of situation may arise in future where we would need to redesign or upgrade the protocol and trace-cmd should then be able to show meaningful message to user to upgrade the binary. We might also be hitting protocol bugs as well down the lane and versioning would become necessary. >> - for (i = 0; i < tmap.max_cpus; i++) >> - tmap.map[i] = -1; > >Note, we wrote this with -1, because we envisioned working with hypervisors >that may not be Linux, and that PID = 0 may be legitimate. > Thanks for the clarification. >We'll have to investigate a solution for this further. Sure, I will have a look at this again and see if/how we can fix this without touching existing protocol. I was thinking about adding the pid details to debugfs and then reading it from there. Its not optimal as we would need a supporting kernel, but it would be accurate if we have kernel support and we need not rely on trace messages to get the pids. Thanks, Vineeth
|