From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brendan Cully Subject: Re: Re: [PATCH] Remus breaks the build Date: Wed, 18 Aug 2010 13:39:12 -0700 Message-ID: <20100818203912.GE2411@kremvax.cs.ubc.ca> References: <4C6493ED.3040605@goop.org> <20100813194217.GA6981@kremvax.cs.ubc.ca> <4C65B5A5.8020202@goop.org> <20100818202650.GD2411@kremvax.cs.ubc.ca> <840C91E9-A05F-49CE-B770-A96CCC65E975@linode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <840C91E9-A05F-49CE-B770-A96CCC65E975@linode.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jed Smith Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wednesday, 18 August 2010 at 16:34, Jed Smith wrote: > On Aug 18, 2010, at 4:26 PM, Brendan Cully wrote: > > > On Friday, 13 August 2010 at 14:14, Jeremy Fitzhardinge wrote: > >> On 08/13/2010 12:42 PM, Brendan Cully wrote: > >>> I assume you're talking about this snippet of tools/remus/kmod/Makefile: > >>> > >>> $(MAKE) -C $(KERNELDIR) SUBDIRS=`pwd` modules > >>> > >>> which expects to find a Makefile in $KERNELDIR but does the actual > >>> building in place, in the tools/remus/kmod directory (unless the > >>> kernel build system has changed recently?). I thought this was a > >>> pretty standard way to build out-of-tree kernel modules. > >> > >> I don't ever build the kernel out of the Xen tree. In general, it > >> assumes the kernel tree has already been configured and built, which may > >> not be true if you're doing a parallel build, or if you're building the > >> Xen tree piecewise. > >> > >>> I'm not sure why this is causing you problems (is it?), but if you're > >>> willing to carry sch_queue in the pvops tree, I'd be happy to drop > >>> tools/remus/kmod in the unstable tree. > >> > >> Yes, I'm happy to include it. Do you have a git reference I can merge from? > > > > That's more git than I've learned. Would a patch suffice? (even > > producing the diff was non-obvious. It turns out that git add foo; git > > diff doesn't include the diff for foo!) > > Because you staged it. git-diff(1) works before you stage the changes. You > probably want to commit and use git-format-patch(1). > > http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html Not that it really matters (I was just sneaking in a rant, and I did manage to produce the diff), but git diff also didn't include the new file before I added it. It parts ways here with every other version control system I can remember, not to mention intuition. But hey, that's their problem.