[ovs-dev] [patch 0/5] datapath: post-2.6.35 compatibility

[Simon Horman]

On Sun, Aug 08, 2010 at 05:49:20PM -0400, Jesse Gross wrote:
> On Fri, Aug 6, 2010 at 11:05 AM, Simon Horman <horms at verge.net.au> wrote:
> 
> > This series of patches aims to add compatibility to datapath with
> > Linux's current tree.
> >
> > The main aim of this is to allow datapath to compile against
> > that tree so that we can submit datapath for inclusion in the kernel.
> >
> > I apologise for these changes being  little rougher and a in particular
> > untested beyond compilation, but I wanted to get them out before
> > I go to LinuxCon next week.
> 
> 
> Great, thank you for this.
> 
> I included some inline comments in the actual patches but wanted to give a
> quick description of our compatibility code, since this is focused in this
> area.
> 
> Our current goal is to support released kernels 2.6.18+.  Since quite a bit
> has changed over that time we need to be somewhat careful about how we
> handle compatibility in order to still have readable code.
> 
> The first component is that we only support released kernels.  Supporting
> changes at the commit level just adds an order of magnitude more complexity,
> so we don't try.  Obviously we'll have to track current changes more closely
> as we try to go upstream.  However, we don't need to try to retain support
> for intermediate versions that are not released and not HEAD.
> 
> The second area is that we try to cut down on #ifdef's as much as possible
> in the main code base and confine them to the compat directory.  In
> particular we try to make our main code base use functions taken from the
> most recent version of the kernel and then write compatibility layers to the
> extent possible for older kernels.  In theory, this means that if we were to
> merge into the newest kernel we could just delete the compat directory and
> everything would just work.  Since we'll have to delete compatibility code
> anyways when merging upstream, this helps us keep that work to a minimum.
> 
> Keeping all the compatibility code in a single directory isn't always
> completely possible and is really limited to individual functions that have
> either been added or changed.  When this isn't possible we just try to keep
> the version specific code to a minimum and abstracted to keep it from being
> too much of an eyesore.  vport-netdev.c has more than its share of this code
> since it directly interacts the most with the rest of the kernel but we
> still try to do what we can to minimize it.

Hi Jesse,

thanks for your advice. Particularly on ways to simplify things.
I'll re-spin and repost my patches accordingly.