Re: Xen "pvhvm" driver support for squeeze?
On Thu, 2010-08-19 at 14:19 +0100, Ian Campbell wrote:
> On Thu, 2010-08-19 at 15:15 +0200, Bastian Blank wrote:
> > On Thu, Aug 19, 2010 at 01:07:05PM +0100, Ian Campbell wrote:
> > > Is this git tree available somewhere?
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>
> Thanks,[...]
So I tried (the two SHA1 are identified in the pvops.patch header):
$ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf
$ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671
$ git diff v2.6.32.19..HEAD
and this seemed to give me a patch a little bit like, but not close
enough to be useful, to the current pvops.patch. If I attempt to
run ./debian/rules source using this patch to replace the existing one
(without none of the pvhvm stuff included) then I get:
--> Try to apply base-extra.
--> base-extra fully applied.
--> Try to apply 3-extra.
--> 3-extra fully applied.
--> Try to apply 4-extra.
--> 4-extra fully applied.
--> Try to apply 10-extra.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_bios.c.rej
2 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_lvds.c.rej
1 out of 4 hunks FAILED -- saving rejects to file drivers/ssb/pci.c.rej
1 out of 3 hunks FAILED -- saving rejects to file drivers/usb/serial/option.c.rej
2 out of 2 hunks FAILED -- saving rejects to file fs/proc/array.c.rej
2 out of 2 hunks FAILED -- saving rejects to file include/linux/sched.h.rej
1 out of 2 hunks FAILED -- saving rejects to file include/linux/ssb/ssb.h.rej
3 out of 3 hunks FAILED -- saving rejects to file kernel/exit.c.rej
1 out of 1 hunk FAILED -- saving rejects to file kernel/fork.c.rej
1 out of 7 hunks FAILED -- saving rejects to file kernel/sched.c.rej
3 out of 3 hunks FAILED -- saving rejects to file kernel/sys.c.rej
1 out of 10 hunks FAILED -- saving rejects to file mm/memory.c.rej
(+) FAIL features/all/xen/pvops.patch
So I then fixed up pvops.patch by hand to resolve the above issues. The
tree resulting from this had loads of differences from the tree before I
tried to original tree using the original pvops.patch.
I then tried
$ git diff v2.6.32.17..HEAD
since this is what the current pvops.patch appears to be based on (this
is sane I guess since that was the base version for 69a73fa in xen.git).
It was a lot closer but still not identical, and using it results in:
--> Try to apply base-extra.
--> base-extra fully applied.
--> Try to apply 3-extra.
--> 3-extra fully applied.
--> Try to apply 4-extra.
--> 4-extra fully applied.
--> Try to apply 10-extra.
7 out of 7 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_32.h.rej
4 out of 4 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_64.h.rej
1 out of 29 hunks FAILED -- saving rejects to file arch/x86/xen/enlighten.c.rej
2 out of 8 hunks FAILED -- saving rejects to file arch/x86/xen/time.c.rej
1 out of 20 hunks FAILED -- saving rejects to file drivers/xen/events.c.rej
1 out of 1 hunk FAILED -- saving rejects to file include/linux/interrupt.h.rej
1 out of 1 hunk FAILED -- saving rejects to file kernel/irq/manage.c.rej
(+) FAIL features/all/xen/pvops.patch
Error: Patch failed
Resolving the rejects was pretty trivial but still left a diff compared
with the starting point:
$ diff -purN -X /home/ijc/development/dontdiff.txt debian/build/source_amd64_xen/ ../build.pristine/source_amd64_xen/ | diffstat -p4
arch/x86/xen/Kconfig | 4
arch/x86/xen/enlighten.c | 4
arch/x86/xen/time.c | 6
drivers/net/xen-netfront.c | 13 +
drivers/xen/blktap/blktap.h | 94 +++------
drivers/xen/blktap/control.c | 237 +++++++++++------------
drivers/xen/blktap/device.c | 434 ++++++++++++++++++++++---------------------
drivers/xen/blktap/request.c | 2
drivers/xen/blktap/ring.c | 383 ++++++++++++++++++++++---------------
drivers/xen/blktap/sysfs.c | 301 +++++++++++------------------
10 files changed, 738 insertions(+), 740 deletions(-)
Some of that is likely the impact of stuff going into 2.6.32.x but some
of it (e.g. the blktap stuff) clearly isn't.
I have a feeling that with a little more manual tweaking I could make it
fit and produce the same result as before -- but this doesn't fit with
your earlier statement:
> The patch is a simple git diff, nothing modified to work.
At a minimum you must be doing something more complex the a "simple git
diff", but I am unable to infer what that is.
If you are going to NACK patches on the basis that they don't follow
some specific set of steps/rules which you have for updating things I
think it is only reasonable to ask that you publish precisely what those
steps/rules are so that people stand at least some chance of doing what
you want. Otherwise I think it is entirely reasonable for others to
update the patch in whatever way they see fit.
Ian.
--
Ian Campbell
Current Noise: Mistress - At Arms Length
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
Reply to: