On Fri, 2024-05-03 at 15:14 -0700, Andrii Nakryiko wrote: [...] > With the decomposition into sort + emit string representation, it's > now trivial to use in this flexible way. > > Thoughts? Compared to callbacks for attributes this adds the following: - ability to filter-out some types; - ability to add some pre-processor statements between specific types. Compared to callbacks for attributes this lacks the following: - ability to specify attributes for nested anonymous types (not important for preserve_access_index). As I ranted in the off-list discussion, full flexibility is achievable only with some kind of C AST: - an API to produce such an AST; - an API to modify AST where necessary; - an API to serialize the AST as C code. Adding such AST to libbpf is completely out of scope. So, what we are left with is a set of half-measures: 1. a fixed attribute string as in Jose's patch; 2. a callback before printing attributes as suggested by me; 3. two API functions to get a sorted list of types and to print a type as suggested by Andrii. And a set of use-cases: a. capability to add some attribute for all structs; b. capability to add some attribute for specific types; c. capability to filter printed types. (1) covers only (a); (2) covers (a,b); (3) covers (a,b,c). Still, (3) has limited flexibility and I do not exclude the necessity to add some sort of (2) in the future. On the other hand, necessity to modify dump output arises not often, so I think that (3) is preferable at the moment.
