[openfabrics-ewg] Where do contribute new stuff to OFED scripts?

[Michael S. Tsirkin]

Quoting r. Hoang-Nam Nguyen <HNGUYEN at de.ibm.com>:
> Subject: Re: [openfabrics-ewg] Where do contribute new stuff to OFED scripts?
> 
> > How about the usual time slot on Monday, 25 Sep?
> > - Noon-1pm US Eastern
> > - 9-10am US Pacific
> > - 7-8pm Israel
> Hm, might not be simple for me to call in due to a schedule conflict for
> that week Sep 25-28.
> However, due to the need of this call, I'll try or at least another
> colleague will do.

Why the rush? OFED 1.1 will be out with current methodology.

> Not sure if this has been mentioned by this discussion, a clear backport
> procedure for
> OFED would help much.
> Thanks!
> Nam Nguyen

Why didn't you ask? I don't think we need a conf call *for that*.
It's actually quite simple - here's a 4 pint list:

1. directories ofed_scripts, kernel_patches, include/rdma and
   drivers/infiniband are checked out from ofed tree, and put in a tarball.

2. User unpackets the tarball, and softlinks scripts from under
   ofed_scripts to current directory

3. ofed script "confiure" is run with required kernel version

It locates kernel_patches directory, and applies
all patches uner the fixes directory there.

Then takes the backports/<kernel version>/
and applies patches from there.

Note: patches are applied on alphanumeric order.
So while it's best to splitpatches in a way that makes the, independent
(see technique described below that helps),
sometimes you need to force a specific order - just call patches
foo_1.patch foo_2.patch

4. "make kernel" command is run.

The IB stack is built as an of out tree module.
during build, Makefile passes flags to make the local directories
include/ and drivers/infiniband/include be located by preprocessor
*before* the kernel directories.

That's it!
But a note to elaborate the last point: this trick makes it possible
to backport a lot of code without changing the code itself.
For example, let's assume that your code uses sk_east_skb which gets
3 parameters under 2.6.18 but 2 under 2.6.17 - and we actually pass
0 as the third parameter, so we'd like o make a call with 2 paremeters
uner 2.6.17.

So, we put the following patch under backport/2.6.17:

Index: last_stable/drivers/infiniband/include/net/sock.h
===================================================================
--- /dev/null
+++ last_stable/drivers/infiniband/include/net/sock.h
@@ -0,0 +1,8 @@
+#ifndef _NET_SOCK_SLES_BACKPORT_H
+#define _NET_SOCK_SLES_BACKPORT_H
+
+#include_next <net/sock.h>
+
+#define sk_eat_skb(a, b, c) sk_eat_skb(a, b)
+
+#endif

Now preprocessor looking for net/sock.h finds our file first,
include_next pulls in the standard kernel headers,
and then sk_eat_skb gets overriden with a mcro that skips
the last parameter.

While this technique is not universal (esp. structure members
can not be dealt with in this way), it makes backports
much less fragile than touching the code itself, so that's
the preferred technique for dealing with backports.

Questions? Comments?
If there are some, post them on the list.

-- 
MST