On Mon, Jun 27, 2022 at 2:03 PM Daniel Müller <deso@xxxxxxxxxx> wrote: > > On Fri, Jun 24, 2022 at 02:09:33PM -0700, Andrii Nakryiko wrote: > > On Wed, Jun 22, 2022 at 10:22 AM Daniel Müller <deso@xxxxxxxxxx> wrote: > > > > > > On Tue, Jun 21, 2022 at 12:41:22PM -0700, Joanne Koong wrote: > > > > Do BTF_KIND_FLOAT and BTF_KIND_TYPEDEF need to be checked as well? > > > > > > Lack of BTF_KIND_TYPEDEF is a good question. I don't know why it's missing from > > > bpf_core_types_are_compat() as well, which I took as a template. I will do some > > > testing to better understand if we can hit this case or whether there is some > > > magic going on that would have resolved typedefs already at this point (which is > > > my suspicion). > > > My understanding why we don't cover floats is because we do not allow floating > > > point operations in kernel code (right?). > > > > FLOAT is an omission, we need to add it (kernel types do have floats). > > [...] > > Thanks for clarifying. Let's leave FLOAT support for follow-on changes, though, > and not bloat this patch set unnecessarily. It's not currently support by the > existing libbpf/kernel checks or by bpftool's BTF minimization logic from what I it seems to be handled by bpf_core_fields_are_compat(), but yeah, we can do a follow up for this > can tell -- preferably all of which would need to be updated, tests be added, > etc. This is entirely orthogonal to what is being added here from my > perspective. > > Thanks, > Daniel
