On Mon, Nov 07, 2011 at 02:16:50PM -0800, Jesse Gross wrote: > On Mon, Nov 7, 2011 at 1:28 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Mon, Nov 07, 2011 at 11:03:11AM -0800, Jesse Gross wrote: > >> On Mon, Nov 7, 2011 at 9:22 AM, Ben Pfaff <b...@nicira.com> wrote: > >> > The kernel netlink code is not as picky as ours, BTW: generally it > >> > only validates minimum lengths. ??Maybe we should only do that in > >> > userspace too; it would simplify a few things. ??Any thoughts on that? > >> > >> Does anyone ever try to send extended structures that are the same at > >> the beginning but have extra information at the end? ??It would be a > >> somewhat weird form of compatibility code but it would depend on only > >> checking the min length. > > > > The libnl manual page here alleges that extensions are done this way > > "frequently": > > ?? ?? ?? ??http://www.infradead.org/~tgr/libnl/doc/core.html > > > > I guess I should go through and drop most uses of maxlen. > > Interesting, I don't think I've ever seen something that does this in > practice. > > >> Otherwise, I don't have particularly strong feelings. ??Would it > >> actually simplify things all that much though? > > > > I was thinking that we could drop maxlen entirely, but in fact it's > > pretty useful for string data, so no, it wouldn't really simplify > > anything. ??Never mind. > > Yeah, I think it's useful in general but it sounds like we shouldn't > be using it for structures.
Hmm, we could actually reduce struct nl_policy to a single "unsigned int" where we have one high bit to signal that it's a string, another high bit to signal that it's optional, and use the low-order bits to specify either the minimum payload length (for non-strings) or maximum payload length (for strings). But this is probably a waste of time. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
