On 18/10/18 19:12, Martin Lau wrote: > The BTF verification and bpf_prog_load() has to treat > them differently. > > Are you suggesting they can be treated the same for > the kernel verification purpose? > > or > > The concern is, having two kind, BTF_KIND_FUNC_PROTO and > BTF_KIND_FUNC, is confusing because they have almost the > same BTF metadata? > > From the BTF perspective, they are different because > they are allowed to contain different information. > For example, only "foo" can have func_info in patch 5 > (the to-be-added line_info can only belong to "foo" also). Perhaps I'm not properly understanding how BTF is to be used. But from my perspective, 'foo' is not a type; it's an instance of a type; i.e. it's a value of type int ()(int). Then by a kind of metonymy, we are including a BTF record that defines the type 'foo' as int()(int), in order to state that this is the type _of_ foo. Similarly, we are including a BTF record defining 'bar' as the type int (*)(int), thus stating that the type _of_ bar is int (*)(int). So everything that's special about 'foo' relates to the fact that it is a named, rather than anonymous, type, which is being used to indicate that there is an actual object 'foo' of this type. And this is *identical* to how the BTF record "name 'a', type int" declares an object a, the BTF record "name 'b', type int *" declares an object b, and the anonymous int type referenced by b's btf_type.type does not declare an object.
So either types and objects are represented the same way in BTF, or not; it's inconsistent to make a distinction between them for functions but not for other types. I know C thinks functions are special, but that's a wart in C that maybe makes sense in its context but not elsewhere. -Ed
