Grant Grundler wrote:
On Wed, May 17, 2006 at 07:40:07AM -0700, Roland Dreier wrote:
Yes, I agree. That's why I think we should get rid of the
"linux-kernel" part of the svn tree entirely. Because everyone who
wants to test new code seems to run last stable kernel + svn drivers
instead of the new development kernel.
That's because openib guarantee SVN drivers will build with last
stable kernel. Change that policy and document the steps
that folks should follow. I'd be willing to occasionally try
newer kernels if you think that's what we should be doing.
Please note that both approaches suggested above will not force to test
latest IB code with the under-development kernel...
This is b/c most of the code (specifically the already in-tree) has zero
backport to the latest stable kernel, eg the kernel portion of OFED
which is targeted for 2.6.16 is based on the for-2.6.17 branch of
Roland's GIT tree (expect for the components not there yet, which are co
from the SVN), but OFED is not tested with (does not support) 2.6.17-rcX
The same "trick" would work also with Grant's approach.
So there's no replacement for testing done at least by the openib
maintainers (and distros!!! when they start moving to IB...) for:
+1 next-kernel-RC-versions downloaded from kernel.org (eg 2.6.17-RCX)
+2 next-next-kernel-branches of infiniband.git (Roland's tree)
Ofcourse people are busy, and testing is derived from needs.. for
example the iSER maintainers (...) are testing now with what's closet to
2.6.18 and i guess the ipath maintainers are testing with 2.6.17-rc4
But at some point of the cycle, its a must that each maintainer would
test his/her code with next-kernel-RC-versions from kernel.org
Or.
Or.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general