On 03/10/2024 15:53, Arnaldo Carvalho de Melo wrote: > On Thu, Oct 03, 2024 at 03:40:35PM +0100, Alan Maguire wrote: >> On 03/10/2024 00:52, Stephen Brennan wrote: >>> So far, pahole has only encoded type information for percpu variables. >>> However, there are several reasons why type information for all global >>> variables would be useful in the kernel: > >>> 1. Runtime kernel debuggers like drgn could use the BTF to introspect >>> kernel data structures without needing to install heavyweight DWARF. > >>> 2. BPF programs using the "__ksym" annotation could declare the >>> variables using the correct type, rather than "void". > >>> It makes sense to introduce a feature for this in pahole so that these >>> capabilities can be explored in the kernel. The feature is non-default: >>> when using "--btf-features=default", it is disabled. It must be >>> explicitly requested, e.g. with "--btf-features=+global_var". > >> I'm not totally sure switching global_var to a non-default feature is >> the right answer here. > >> The --btf_features "default" set of options are meant to closely mirror >> the upstream kernel options we enable when doing BTF encoding. However, >> in scripts/Makefile.btf we don't use "default"; we explicitly call out >> the set of features we want. We can't just use "default" in that context >> since the meaning of "default" varies based upon whatever version of >> pahole you have. > >> So "default" is simply a convenient shorthand for pahole testing which >> corresponds to "give me the set of features that upstream kernels use". >> It could have a better name that reflects that more clearly I suppose. > >> When we do switch this on in-kernel, we'll add the explicit "global_var" >> to the list of features in scripts/Makefile.btf. > >> So with all this said, do we make global_vars a default or non-default >> feature? It would seem to make sense to specify non-default, since it is >> not switched on for the kernel yet, but looking ahead, what if the 1.28 >> pahole release is used to build vmlinux BTF and we add global_var to the >> list of features? In such a case, our "default" set of values would be >> out of step with the kernel. So it's not a huge deal, but I would >> consider keeping this a default feature to facilitate testing; this >> won't change what the kernel does, but it makes testing with full >> variable generation easier (I can just do "--btf_features=default"). > > This "default" really is confusing, as you spelled out above :-\ When to > add something to it so that it reflects what the kernel has is tricky, > perhaps we should instead have a ~/.config/pahole file where developers > can add BTF features to add to --btf_features=default in the period > where something new was _really_ added to the kernel and before the next > version when it _have been added to the kernel set of BTF features_ thus > should be set into stone in the pahole sources? > it's a nice idea; I suppose once we have more automated tests, this will be less of an issue too. I'm looking at adding a BTF variable test shortly, would be good to have coverage there too, especially since we're growing the amount of info we encode in this area. > So I think we should do as Stephen did, keep it out of > --btf_features=default, as it is not yet in the kernel set of options, > and have the config file, starting with being able to set those > features, i.e. we would have: > > $ cat ~/.config/pahole > [btf_encoder] > btf_features=+global_var > > wdyt? > I think that makes perfect sense, great idea! Alan
