On Tue, Dec 17, 2019 at 3:37 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 12/17/19 9:16 PM, Alexei Starovoitov wrote: > > On Tue, Dec 17, 2019 at 08:50:31PM +0100, Daniel Borkmann wrote: > >>> > >>> Yes, name collision is a possibility, which means users should > >>> restrain from using LINUX_KERNEL_VERSION and CONFIG_XXX names for > >>> their variables. But if that is ever actually the problem, the way to > >>> resolve this collision/ambiguity would be to put externs in a separate > >>> sections. It's possible to annotate extern variable with custom > >>> section. > >>> > >>> But I guess putting Kconfig-provided externs into ".extern.kconfig" > >>> might be a good idea, actually. That will make it possible to have > >>> writable externs in the future. > >> > >> Yep, and as mentioned it will make it more clear that these get special > >> loader treatment as opposed to regular externs we need to deal with in > >> future. A '.extern.kconfig' section sounds good to me and the BPF helper > >> header could provide a __kconfig annotation for that as well. > > > > I think annotating all extern vars into special section name will be quite > > cumbersome from bpf program writer pov. > > imo capital case extern variables LINUX_KERNEL_VERSION and CONFIG_XXX are > > distinct enough and make it clear they should come from something other than > > normal C. Traditional C coding style uses all capital letters for macroses. So > > all capital extern variables are unlikely to conflict with any normal extern > > vars. Like vars in vmlinux and vars in other bpf elf files. > > But still, how many of the LINUX_KERNEL_VERSION or CONFIG_XXX vars are actually > used per program. I bet just a handful. And I don't think adding a __kconfig is > cumbersome, it would make it more self-documenting in fact, denoting that this > var is not treated the usual way once prog linking is in place. Even if all > capital letters. Tomorrow, we'd be adding 'extern unsigned long jiffies' as > another potential example, and then it gets even more confusing on the 'collision' > side with regular BPF ELF. Same here, instead of __kconfig, this could have a > __vmlinux or __kernel annotation in order to document its source for the loader > (and developer) more clearly and also gives flexibility wrt ".extern.xyz" > subsections on how we want to map them. Sounds reasonable and clean enough. Let me play a bit with this and see how this all plays together.
