[ovs-dev] Merging datapath into the upstream kernel tree
arnd at arndb.de
Fri Aug 6 02:25:23 PDT 2010
On Thursday 05 August 2010, Ben Pfaff wrote:
> I agree with most of what you wrote. Some comments:
> On Thu, Aug 05, 2010 at 11:31:00AM +0200, Arnd Bergmann wrote:
> > On Thursday 05 August 2010, Simon Horman wrote:
> > > > - Support network namespaces.
> > >
> > > That sounds more like post-merge material to me.
> > Yes, for drivers/staging, it's fine to make the code depend on
> > !CONFIG_NET_NS, but I think it's important enough to fix this
> > before the code can move to drivers/net.
> The current code builds fine with CONFIG_NET_NS. It's just that it only
> uses the initial network namespace, ignoring any others. It should be
> straightforward to add support, whenever we do it.
> > > Unfortunately/fortunately I will be more or less off-line next week
> > > for LinuxCon in Boston. So it will be difficult for me to make a concrete
> > > start on anything before that is finished. If any Open vSwitch people
> > > will be in Boston next week, it would be a good chance to meet.
> > I'll also be in Boston. A few weeks ago, I have tried getting the module
> > code into a state where it could be sent as a patch to the staging tree,
> > but before I had it complete, I realized that there is no Signed-off-by:
> > in the git tree, which means I don't want to send it myself.
> We haven't been making a habit of using Signed-off-by: in the Open
> vSwitch tree at large, because our lawyers didn't tell us that we had
> to. We have, however, been adding them in the xenserver/ subdirectory,
> since Citrix pulls files directly from there and wants the sign-offs, so
> we could start doing so for kernel code also.
It depends on how you want to handle future changes after the code is
upstream. I suppose you will need to keep your own tree at least for
some time in order to support older kernel versions, and you will also
want a cloned kernel tree to make changes that get pulled into
net-next and from there to upstream Linux.
The kernel tree obviously needs the S-o-b, while for your own tree there
is no requirement (you know who wrote the code). If you want to automate
the process of applying patches to both trees like I assume you do
for xenserver, that would mean having S-o-b in both.
More information about the dev