On Thu, Jun 18, 2020 at 06:06:49PM -0700, Andrii Nakryiko wrote: SNIP > > > +/* > > > + * The BTF_ID_LIST macro defines pure (unsorted) list > > > + * of BTF IDs, with following layout: > > > + * > > > + * BTF_ID_LIST(list1) > > > + * BTF_ID(type1, name1) > > > + * BTF_ID(type2, name2) > > > + * > > > + * list1: > > > + * __BTF_ID__type1__name1__1: > > > + * .zero 4 > > > + * __BTF_ID__type2__name2__2: > > > + * .zero 4 > > > + * > > > + */ > > > +#define BTF_ID_LIST(name) \ > > > > nit: btw, you call it a list here, but btfids tool talks about > > "sorts". Maybe stick to consistent naming. Either "list" or "set" > > seems to be appropriate. Set implies a sorted aspect a bit more, IMO. so how about we keep BTF_ID_LIST as it is and rename BTF_WHITELIST_* to BTF_SET_* > > > > > +asm( \ > > > +".pushsection " SECTION ",\"a\"; \n" \ > > > +".global " #name "; \n" \ > > > > I was expecting to see reserved 4 bytes for list size? I also couldn't > > find where btfids tool prepends it. From what I could understand, it > > just assumed the first 4 bytes are the length prefix? Sorry if I'm > > slow... > > Never mind, this is different from whitelisting you do in patch #8. > But now I'm curious how this list symbol gets its size correctly > calculated?.. so the BTF_ID_LIST list does not care about the size, each symbol in the 'list' gets resolved based on its __BTF_ID__XX__symbol__XX symbol the count is kept in BTF_WHITELIST_* list because we need it to sort it and search in it thanks, jirka
