[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-4.0-testing test] 2061: regressions - FAIL



On Fri, 2010-09-03 at 19:04 +0100, Brendan Cully wrote:
> On Friday, 03 September 2010 at 18:55, Ian Jackson wrote:
> > Brendan Cully writes ("Re: [Xen-devel] [xen-4.0-testing test] 2061: 
> > regressions - FAIL"):
> > > Until the kernel modules are in their proper place, I think a less
> > > drastic fix for your test suites would be to edit
> > > tools/remus/kmod/Makefile and change
> > > 
> > > test -d $(KERNELDIR)
> > > 
> > > to
> > > 
> > > test -f $(KERNELDIR)/Module.symvers
> > > 
> > > which will still silently fail to build the modules if tools/remus
> > > builds too early, but should suppress failure warnings. Completely
> > > untested.
> > 
> > I don't think this is reliable, is it ?  As that .symvers file can be
> > created before the kernel build is complete.  So we can still reenter
> > the whole kernel build.
> 
> What do you mean 'reenter the whole kernel build'? Are you under the
> impression that the kmod tree is somehow actually building in the
> kernel build directory?
> 
> As I said in an earlier email, it doesn't do that. It is just using
> the kernel header files, like any other third party module. Normally
> you could find them under /lib/modules/foo/build, but obviously that
> doesn't apply here.

Out of tree module builds require a configured kernel tree, which it is
not when the race is lost. You can't use the kernel headers to build
modules without a .config for example since they contain various #ifdef
CONFIG_FOO stuff which affects the kernel ABI.

Maybe we should drop the remus stuff from tools/Makefile and add an
explicit call to "make -C tools/remus" (or whatever the path is) at the
appropriate place at the end of the rule which builds the kernel?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.