[openib-general] InfiniBand compilation testing

Nishanth Aravamudan nacc at us.ibm.com
Sat Sep 24 11:08:50 PDT 2005


On 24.09.2005 [10:19:53 -0700], Roland Dreier wrote:
>     Nish> I have a prototype of something similar running right now,
>     Nish> to help test InfiniBand, both in mainline and in the svn
>     Nish> repo. Basically, every night (this part hasn't been set up
>     Nish> yet, but should be nothing more than a crontab entry), I can
>     Nish> spawn a build job for InfiniBand. Currently, it will only
>     Nish> cover compile-testing in the following sense: build current
>     Nish> -git with IB options set to =y and =m in x86 and ppc64; and
>     Nish> build current -git with the current svn code linked and IB
>     Nish> options set to =y and =m in x86 and ppc64.
> 
> This is great, thanks!  The build of latest git + latest svn might not
> always succeed, because we try to keep svn working with the latest
> full kernel release, but it's still very helpful to get advance
> warning of API changes that will break our tree.

Right, I figured the more unstable compile-test (git + svn) may be
slightly less useful, but it was far more interesting to get working in
the framework we have :) And now that I have it consistently running,
it's no extra work to add those compile tests.

>     Nish> I have attached below my results from 2.6.14-rc2-git3. Only
>     Nish> build failure was the gen2 kernel code under ppc64 with
>     Nish> everything set to y.
> 
> I just checked in a fix for this -- the pci_pretty_name() API has gone
> away, so I removed our use of it in svn.  I don't understand how your
> other builds of git + svn succeeded though, since pci_pretty_name is
> completely gone.  Oh, I guess you'll miss link failures when building
> modules, so functions that disappear won't break the build.  Still,
> how did the x86 =y build succeed?

The git + svn builds on x86 with =y did not succeed due to gcc errors on
those machines. I am rerunning everything 2.6.13-rc2-git4 on machines I
know are capable of building and will send out a new mail in a little
bit (only two more jobs left to complete).

> Also, is there any way to set this up to spam me when a build fails?

Eventually, probably. Initially, I will keep bouncing mails to you and
openib-general, when things go bad. I will try to figure out a good way
to automagic this part, but it's a little lower priority ...

> Of course, the next step is to add some real IB hardware to the test
> farm and start running regression tests.  (And yes I know that's a lot
> of work ;) But even just seeing if the drivers load successfully would
> be quite useful.

Indeed! That in fact is the next *planned* step. In fact, we do have h/w
that probably could be used, but it's a matter of getting the machines
in the harness and doing some testing to make sure it's working ok. We
also would like to do userspace builds off the svn tree and run whatever
tests are available. That will be more work, of course, and requires
some autobuilding capability across all openib userspace tools (that
functionality really makes the testing simpler). One of our team-members
is working on that part, but is currently occupied elsewhere. We'll keep
the community posted on any progres we make (including contributing back
any fancy Makefiles we eventually come up with to build *everything* :)

Hopefully, once I'm sure my build-tests are successful from cron, I can
take a look at minimally booting the kernels I'm building.

Finally, the way I have things set up right now, I generate .config
sections in the following way (excuse the amazingly long line):

for option in $(find $DEV_TREE_PREFIX/drivers/infiniband -type f -name Kconfig -exec grep ^config {} \; | grep -iv debug | cut -f 2 -d " "); do
	echo CONFIG_$option=y >> $OPENIB_YES_CONFIG_FILE
	echo CONFIG_$option=m >> $OPENIB_MOD_CONFIG_FILE
done

Basically meaning I either turn all options (except for debug) either =y
or =m. Now, I could try and generate combinations of those, but I'm not
sure if I can always guarantee the combinations will be consisten
relative to Kconfig dependencies. Would such combinations be useful?

Thanks,
Nish



More information about the general mailing list