On Mon, 23 May 2022 09:39:45 -0400 Vineeth Pillai <vineethrp@xxxxxxxxxx> wrote: > 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 We actually have that. We are currently at version 3. If this becomes too much of an issue, we can always move to v4. But to do that would require a lot more thinking, as I like to support all versions, and I don't want to have a lot of them. Thus, if we need to update to v4. It would likely be a entirely new protocol to fix and extend the issues of v3. > >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. That would be useful too, in more than just trace-cmd I believe. -- Steve
|