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

Jesse Gross jesse at nicira.com
Wed Aug 18 21:17:38 UTC 2010


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.


>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100818/6fbb1ecb/attachment-0003.html>


More information about the dev mailing list