[ovs-dev] [genl 3/6] netlink-notifier: New function nln_set_mcgroup().

[Ben Pfaff]

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 <blp at 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.
> >