2024-02-29 00:59 UTC+0000 ~ Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> > On Mon, Feb 26, 2024 at 1:48 PM Bryce Kahle <bryce.kahle@xxxxxxxxxxxxx> wrote: >> >> On Fri, Feb 2, 2024, at 2:10 PM, Andrii Nakryiko wrote: >>> But yes, you'd have to specify both vmlinux and all the module >>> BTFs at the same time (which bpftool allows you to do easily with its >>> CLI interface, so not really a problem) >> >> I didn't see a way to specify a directory for vmlinux and all the >> modules BTFs. Are you suggesting I specify the path to each >> individually? I didn't see a way to do that with the current CLI api. >> It assumes that the input is only a single path. > > so right now we have > > bpftool min_core_btf <input-btf> <output-btf> <input1.bpf.o> ... <inputN.bpf.o> > > so we'd have to either add a flag and do > > bpftool min_core_btf <input-btf> -E <extra-btf1> -E <extra-btf2> > <output-btf> ... > > or define special key/value pair (we do that for other commands to > specify extra options): > > bpftool min_core_btf <input-btf> extra <extra-btf-1> extra > <extra-btf-2> <output-btf> .... > > This has a tiny chance that user used "extra" as a name of one of > input object file (we can probably disregard). > > Yet another option is to introduce new command, something like > `bpftool min_core_btf_multi ...` and define new convention. > > > OR. We can pivot and say that we do what you want as two steps: > > 1) generate one large combined BTF from multiple BTFs, something along > the lines of `bpftool btf merge <btf1> ... <btfN>`. We'd need to > specify how split BTF should be handled. > > 2) then use existing min_core_btf command with this merged BTF > > I don't know what's best. The two steps is maybe the cleanest option with regards to the command line syntax, but it doesn't feel great to impose an additional step to the user just because we don't want to rework the syntax, I suppose. I'm not a fan of the multiple "-E" flags, it's not super consistent with what we have for other commands. I'd probably go with the "extra" keywords, or the new subcommand name (and mark the former as deprecated?). Yet another option could be to support two alternatives syntaxes for the existing subcommand if the first argument is, say, "input_btf" (and then define this new syntax using keywords for all arguments).
