On 1/29/2024 5:42 PM, Jakub Kicinski wrote: > Whether YNL specs should replace policy dumps completely (by building > the YAML into the kernel, and exposing via sysfs like kheaders or btf) > - I'm not sure. I think I used policy dumps twice in my life. They > are not all that useful, IMVHO... Many older genetlink/netlink families don't have a super robust or specific policy. For example, devlink has a single enum for all attributes, and the policy is not specified per command. The policy simply accepts all attributes for every command. This means that you can't rely on policy to decide whether an attribute has meaning for a given command. Unfortunately, we can't really change this because it ultimately counts as uAPI and we require that existing working functionality continues working in the future. I personally find this too stringent as sending such junk attributes requires someone going out of their way to write the messages and add extra attributes. In most cases I think sane users/software would rather be informed that they are sending data which is not relevant. However, I can understand the point that the userspace software "worked", and we don't want to break existing applications just because of a kernel upgrade. The YNL spec does this by telling you at every layer of nesting which set of attributes are allowed and with what values. Even if we can't enforce this for older families its still useful information to report in some manner. In addition, the YNL spec is more readable than the policy dumps which essentially require a separate tool to parse out everything and convert to something useful.
