On Mon, Dec 6, 2021 at 4:55 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Mon, 6 Dec 2021 05:25:56 +0200 > Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > > > The only reason to have a string is for "trace-cmd dump" - to be able > > to dump some description for unknown sections, we discussed that in > > the past. But now when I'm looking at that again - there is no sense > > to have it only for that reason, the ID is enough. I can remove the > > string from the header. > > I think we also discussed it for when a new section was added that wasn't > known to the current trace-cmd, that it could give a more useful message. > i.e. "This version of trace-cmd does not handle 'New feature here', please > upgrade your trace-cmd". > > That way, the user would at least know why that new feature is not being > processed. > As we discussed, there are two possible approaches for these descriptions: 1. To add a new section with these descriptions, that way there will be no strings in the section headers. I was thinking more about that approach, it will make the parsing much more complicated. As all sections are dynamically located in the file, there is no strict order - that "description" section can be anywhere, even at the end. That way during the parsing these strings will not be available for the sections before, and the description cannot be displayed. To solve that, parsing should be done in two steps - first to find that "description" section to get all the strings, and second to parse the other sections. The description should be part of the section being parsed, that's why I decided to go with the second approach. 2. Have a fixed size description string in the section header, I think 32 bytes should be OK. > -- Steve -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center
|