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).
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.
Xen-devel mailing list