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