[ovs-dev] [patch 4/5] datapath: use rx_handler_data pointer

Simon Horman horms at verge.net.au
Thu Aug 19 02:15:39 UTC 2010


On Wed, Aug 18, 2010 at 05:17:38PM -0400, Jesse Gross wrote:
> On Wed, Aug 18, 2010 at 12:46 AM, Simon Horman <horms at verge.net.au> wrote:
> 
> > > > +/* XXX: Add IFF_OVS_DATAPATH to include/linux/if.h and use it
> > > > + *     in place of IFF_VPORT in this file. */
> > > >
> > >
> > > We could could do this with compatibility code: use the desired name in
> > this
> > > file and then define it to the appropriate value in
> > > compat/include/linux/if.h.  On pre-2.6.36 kernels it could be defined to
> > 0,
> > > defined to IFF_BRIDGE_PORT for later kernels, and then we wouldn't need
> > to
> > > define it all at once we make it upstream.  This would remove a bunch of
> > > #ifdef's from this file.
> >
> > I think we can just unconditionally define it to IFF_BRIDGE_PORT,
> > it will be unused with older kernels. It can then get a unique value
> > after the merge.
> >
> > I don't think that this can remove any #ifdefs from the code
> > as "netdev_vport->dev->priv_flags |= IFF_OVS_DATAPATH" and similar
> > would still be incompatible with older kernels.
> >
> 
> If you #define it to be 0 on the older kernels it will be no-op and
> therefore not incompatible.  That would then allow the removal of the #ifdef
> in the main code path.

Thanks, sorry for not catching that the first time around.
I'll make it so.

> > > There's also a block of code at the bottom of the file that is a hack to
> > > enforce mutual exclusion with the bridge.  Now that we can safely coexist
> > > with the bridge, it can be #if'd out on appropriate kernels.
> >
> > Done. Although registration of the datapath will fail if the bridge is
> > present and vice versa because IFF_OVS_DATAPATH has the same value
> > as IFF_BRIDGE_PORT (for now).
> >
> 
> Well you can only register one handler per device anyways, so it doesn't
> really matter that they have the same flag for now.  The goal of the
> existing code block is to prevent both modules from loading at the same time
> (when there was only a single hook), since that will cause bad things to
> happen.

I agree that its safe to remove the safety measure/hack now.





More information about the dev mailing list