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 <[email protected]> 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 [email protected] http://openvswitch.org/mailman/listinfo/dev
