Re: Re: [PATCH] Remus breaks the build

[Brendan Cully <brendan@cs.ubc.ca>]

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.