On Wed, 27 May 2020 15:59:46 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > But regardless, can you please reply on v1 thread why adding support > for BTF to these special maps (that do not support BTF right now) > won't be a better solution and won't work (as you claimed)? (I will reply here instead of on v1) and I have not claimed it won't work. It will work, but we loose an opportunity if we just allow BTF across the board, without using it for per map validation. We have an opportunity with these special maps, that do not support BTF right now. The value field in these maps are actually a UAPI and also kABI (Binary). Simply describing the struct with BTF is nice, but only helpful to make the end-user understand they binary layout. On the kernel side we are still stuck with a kABI that can only be end-extended and size increased. I want to use BTF on the kernel-side to validate and enforce that user provided the expected "named" layout, and possibly reject it. This gives us a layer that can provide a flexible kABI. From my current understanding of the kernel side code that parse/walk BTF, I we can actually have flexible offsets (for e.g. structs) in the binary value, and remap those on the kernel side. Enforcing a named layout when we enable BTF for these maps, will give us binary flexibility for future changes. I hope you agree? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
