On Wed, 9 Mar 2022 14:43:07 +0100 Ilya Maximets wrote: > >> It's a bit of an uncharted territory, hard to say what's right. > >> It may be a little easier to code up the rejection if we have > >> the types defined (which I think we need to do in > >> __parse_flow_nlattrs()? seems OvS does its own nla parsing?) > > Ack. And, yes, __parse_flow_nlattrs() seems to be the right spot. > OVS has lots of nested attributes with some special treatment in a > few cases and dependency tracking, AFAICT, so it parses attributes > on it's own. Is there a better way?
Looks like OvS has extra requirements like attributes can't be duplicated and zeroed out attrs are ignored. I don't think generic parsers can do that today, although the former seems like a useful addition. A problem for another time. > >> Johannes, any preference? > > > > so why not again just flat enum without ifdefs and without values > > commented out? even if we leave values in comments like above it doesn't > > mean the userspace won't use them by mistake and send to the kernel. > > but the kernel will probably ignore as not being used and at least > > there won't be a conflict again even if by mistake.. and it's easiest > > to read. > > OK. Seems like we have some votes and a reason (explicit reject) to have > them defined. This will also make current user space and kernel definitions > equal. Let me put together a patch and we'll continue the discussion there. Thanks! _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
