On Mon, Nov 7, 2011 at 3:48 PM, Ben Pfaff <b...@nicira.com> wrote: > 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.
Yeah, it seems like more effort than it is worth. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
