Jakub Kicinski <kuba@xxxxxxxxxx> writes: > On Sat, 27 Jan 2024 17:18:59 +0000 Donald Hunter wrote: >> > Hah, required attrs. I have been sitting on patches for the kernel for >> > over a year - https://github.com/kuba-moo/linux/tree/req-args >> > Not sure if they actually work but for the kernel I was curious if it's >> > possible to do the validation in constant time (in relation to the >> > policy size, i.e. without scanning the entire policy at the end to >> > confirm that all required attrs are present). And that's what I came up >> > with. >> >> Interesting. It's definitely a thorny problem with varying sets of >> 'required' attributes. It could be useful to report the absolutely >> required attributes in policy responses, without any actual enforcement. >> Would it be possible to report policy for legacy netlink-raw families? > > It's a simple matter of plumbing. We care reuse the genetlink policy > dumping, just need to add a new attr to make "classic" family IDs > distinct from genetlink ones. > > The policy vs spec is another interesting question. When I started > thinking about YNL my intuition was to extend policies to carry all > relevant info. But the more I thought about it the less sense it made. > > 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... Yeah, fair point. I don't think I've used policy dumps in any meaningful way either. Maybe no real value in exporting it for netlink-raw. >> Thinking about it, usability would probably be most improved by adding >> extack messages to more of the tc error paths. > > TC was one of the first netlink families, so we shouldn't judge it too > harshly. With that preface - it should only be used as "lessons learned" > not to inform modern designs. Oh, not judging TC, just considering whether it would be useful to throw some extack patches at it.
