btf: rename FindType to TypeByName, add TypesByName and TypeByID methods

[ti-mo]

This patch adds two querying primitives to btf.Spec:

• TypeByID() looks up a btf.Type by its ID in the btf.Spec
• TypesByName() returns a list of btf.Types that satisfy the given essential name. This can be used to obtain all CO-RE flavors of a struct, to perform a quick lookup without retaining the result, or if the kind or signature of the type you're looking for is not known up front.

In order to simplify the internal graph bookkeeping, harmonize on a single btf.Type interface all BTF types must implement instead of the Type and NamedType interfaces. This facilitates implementing an intuitive API for querying the graph.

Further document the purpose of essentialName().

[lmb]

I don't understand the idea behind getting rid of NamedType. Is the problem that []Type and []NamedType are not assignable to each other? The code I've written for bpf2go is nicer with NamedType vs. having to check the function return: https://github.com/lmb/ebpf/blob/7f73e6889d42ae315d66e8027140850d71c49d0d/cmd/bpf2go/output.go#L258-L292

[ti-mo]

I don't understand the idea behind getting rid of NamedType. Is the problem that []Type and []NamedType are not assignable to each other?

Yes, the fact that they're both discrete types and that they are/were stored in separate arrays makes it slightly awkward to access them. Also, I don't think it made sense from a data modelling perspective:

• whether a type can have a name or not is a property of a type, not a defining characteristic
• named and unnamed types are not semantically different; even named types can be anonymous, so any code that operates on named types must account for TypeName() == "", which kind of defeats the purpose of having a separate namedType interface to begin with
• the querying interface (here e.g. TypeByID) would need a variant for both kinds of types, which will just cause confusion and might be more painful to implement/maintain than necessary

The code I've written for bpf2go is nicer with NamedType vs. having to check the function return: https://github.com/lmb/ebpf/blob/7f73e6889d42ae315d66e8027140850d71c49d0d/cmd/bpf2go/output.go#L258-L292

Sorry, lacking context, not clear what this code is doing. (comments might help)

---

Now I've had time to mull it over, I think I've also changed my mind about TypeName() returning string, bool:

λ  ebpf tb/multiprog ✓ grep -R "\.TypeName()"
internal/cmd/gentypes/main.go:		if n, _ := cs.TypeName(); !ok || n != "" {
internal/btf/core.go:		localTypeName, _ := localType.TypeName()
internal/btf/ext_info.go:	name, _ := typ.TypeName()
internal/btf/btf.go:		if name, _ := typ.TypeName(); name != "" {
internal/btf/btf.go:		if n, _ := typ.TypeName(); n != name {
internal/btf/types.go:		typeName, _ := typ.TypeName()
internal/btf/format_test.go:				n, _ := t.TypeName()

Currently, there's not a call site that actually uses the bool, and I think this is just more expressive:

if typ.TypeName == "" && typ.IsNamed() {
  return errors.New("some_error")
}

WDYT?

[lmb]

IsNamed() bool is confusing I think because it could mean both name != "" or name can be != "". Let's go with TypeName() string for now and skip the dedicated function. We can figure out what to do once we have the need.

[lmb]

If dealing with struct flavours is too cumbersome we could also change the API, so that resolving struct flavours is the responsibility of the caller? Basically, export essentialName() and add an unexported wrapper for CO-RE which does two lookups. Just an idea.