Sounds good to me, I'll drop this patch and send out an incremental on the final patch.
Ethan On Fri, Aug 26, 2011 at 10:24, Ben Pfaff <b...@nicira.com> wrote: > dpif_linux_init() only ever tries once and either succeeds or fails > for all time. Maybe it should be more tolerant, but that's a separate > issue. > > So I think that it's OK to do it the simple way. > > On Fri, Aug 26, 2011 at 10:11:57AM -0700, Ethan Jackson wrote: >> I did have a reason for doing it this way which may-or-may-not be >> valid. I'm worried about the case where dpif_linux_init() fails, and >> the nln handle is NULL. In this case, no new dpifs will be able to >> register with this NULL nln. Then, if later on dpif_linux_init() >> tries again and is successful, these dpifs which have failed to >> register earlier will continue to be unregistered. >> >> I decided to solve this problem by attempting to guarantee that the >> nln handle is always non-null. Does that sound reasonable? Perhaps I >> should think about doing some sort of restructuring in dpif-linux? >> >> Ethan >> >> On Fri, Aug 26, 2011 at 09:52, Ben Pfaff <b...@nicira.com> wrote: >> > On Thu, Aug 25, 2011 at 04:28:35PM -0700, Ethan Jackson wrote: >> >> This function will be helpful when the multicast group of a >> >> netlink-notifier isn't known at creation time. >> > >> > I see that this gets used in the final commit in this series, but I >> > don't yet see why. ?Why can't dpif-linux determine the multicast group >> > before it creates the netlink notifier? ?Is there a nonobvious >> > ordering issue somewhere in dpif_linux_init()? >> > >> > I didn't fully review this patch yet. >> > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
