WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-4.0-testing test] 2061: regressions - FAIL
From: Brendan Cully <brendan@xxxxxxxxx>
Date: Fri, 3 Sep 2010 11:16:25 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Fri, 03 Sep 2010 11:17:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1283537510.3469.243.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
References: <E1OrNWT-0006tR-VX@xxxxxxxxxxxxxxxxxxx> <19585.11453.829459.233212@xxxxxxxxxxxxxxxxxxxxxxxx> <20100903171729.GA16367@xxxxxxxxxxxxxxxxx> <19585.11893.756884.189394@xxxxxxxxxxxxxxxxxxxxxxxx> <20100903173803.GA17663@xxxxxxxxxxxxxxxxx> <19585.13107.325426.697689@xxxxxxxxxxxxxxxxxxxxxxxx> <20100903175413.GB17663@xxxxxxxxxxxxxxxxx> <19585.13976.404518.700860@xxxxxxxxxxxxxxxxxxxxxxxx> <20100903180428.GC17663@xxxxxxxxxxxxxxxxx> <1283537510.3469.243.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2010-08-04)
On Friday, 03 September 2010 at 19:11, Ian Campbell wrote:
> 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.

Yes. The current kmod Makefile already silently exits if
$(KERNELDIR)/.config isn't there, but .config turns out not to be good
enough. Looking for Module.symvers ought to be sufficient for kmod to
either succeed or silently exit when it loses the race, I
think. $(KERNELDIR)/include/linux/autoconf.h might also do the
trick. But it is obviously much better to have a proper Makefile
dependency.

> 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?

The problematic directory is tools/remus/kmod, but otherwise this
sounds fine to me.

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