[ovs-dev] [PATCH 04/16] datapath: Don't read net namespace on kernels that don't use them.

Ben Pfaff blp at nicira.com
Tue Apr 13 18:02:09 UTC 2010


On Tue, Apr 13, 2010 at 01:52:29PM -0400, Jesse Gross wrote:
> On Tue, Apr 13, 2010 at 1:04 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Tue, Apr 13, 2010 at 10:41:06AM -0400, Jesse Gross wrote:
> > > Use macros to eliminate the network namespace argument before it
> > > gets to the compiler.  This allows us to specify a namespace on
> > > kernels that know about them and prevent the compiler from complaining
> > > on kernels that don't.
> >
> > I'm surprised that this is necessary.  I didn't think that the kernel
> > compiler flags were set up to complain about unused arguments.  But the
> > change seems OK.
> >
> 
> This actually isn't to suppress a warning about unused arguments - it avoids
> an error about an undefined symbol.
> 
> The problem is that when we call the function it look like this:
> 
> rtnl_notify(skb, &init_net, ...);
> 
> init_net isn't defined on kernels before net namespaces were introduced so
> the compiler barfs when it sees it, even though it isn't used.

OK.  I thought that we were doing something clever like defining our own
(empty) init_net but I don't see that so your solution seems good to me
(at least until we have to do the same thing for dozens of functions).

> > One nit: The cast to (void) below should be unnecessary since
> > rtnl_notify() as we define it already has a "void" return type.
> >
> > >  /* No 'net' parameter in these versions. */
> > >  #define rtnl_notify(skb, net, pid, group, nlh, flags) \
> > > -     ((void) (net), (void) rtnl_notify(skb, pid, group, nlh, flags))
> > > +                 ((void) rtnl_notify((skb), (pid), (group), (nlh),
> > (flags)))
> 
> This macro is also used on later kernels where this function is defined but
> not in the form we want (2.6.19-24) so we need the cast to void.

Oops, you're right of course.  I must have been confused by the change
in the "#if"s.




More information about the dev mailing list