|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|