[ovs-dev] [patch 0/5] datapath: post-2.6.35 compatibility
jesse at nicira.com
Sun Aug 8 14:49:20 PDT 2010
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev