On 11/05/2024 10:40, Eduard Zingerman wrote: > On Fri, 2024-05-10 at 11:30 +0100, Alan Maguire wrote: >> Options cover existing parsing scenarios (ELF, raw, retrieving >> .BTF.ext) and also allow specification of the ELF section name >> containing BTF. This will allow consumers to retrieve BTF from >> .BTF.base sections (BTF_BASE_ELF_SEC) also. >> >> Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> >> --- > > For the sake of discussion, what are the benefits of adding > btf__parse_opts(), compared to modifying btf__parse() to check if > .BTF.base is present and acting accordingly? > btf__parse() already does a guess if passed argument is an ELF or a > RAW file, so such guessing semantics seems to be a natural extension. It's a good idea. The only thing I'd say against it is that we already have existing semantics there that are well-established, and the .BTF.base scenario will be relatively rare, yet the check would I think be a tax all .BTF-only cases will have to pay. We'd presumably check .BTF.base, and if not present check for .BTF. So all callers of btf__parse() when accessing .BTF sections would be checking for .BTF.base first. In that context, it seemed to make sense to support an explicit request for a specific section (via btf__parse_opts()) rather than inducing overhead in existing checks. But again, if the overhead isn't seen as an issue, we could absolutely do it.
