Re: Xen "pvhvm" driver support for squeeze?
On Thu, 2010-08-19 at 15:46 +0100, Ian Campbell wrote:
> 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 merge 5473680bdedb7a62e641970119e6e9381a8d80f4 # xen/xen/netfront
$ git merge fbd0ebb445bd413bda719c26c4921c53d9381fe8 # xen/xen/dom0/backend/blktap2
# resolve conflicts in drivers/xen/blktap/device.c
$ git diff v2.6.32.17..HEAD
Got me a patch which, once I trivially removed the hunks which already
exist in the Debian base, was pretty close to the existing pvops.patch:
arch/x86/xen/enlighten.c | 4 ----
arch/x86/xen/time.c | 6 +-----
drivers/xen/blktap/device.c | 17 +++++++++--------
drivers/xen/blktap/sysfs.c | 2 +-
4 files changed, 11 insertions(+), 18 deletions(-)
The arch ones look related to something going into 2.6.32.x but I can't
figure out where the blktap ones are coming from.
$ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf
$ git merge 16938b03e75e70e214d053c527bc937ee8ca838a # xen/xen/next
$ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671
$ git diff v2.6.32.17..HEAD
Then trivially adjust those hunks conflict with the base kernel, gets me
a kernel which precisely matches the existing tree!
So I guess I should rebase the PVHVM patches on v2.6.32.17 and the diff
against that, which should produce the right thing.
Ian.
> $ 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
>
>
--
Ian Campbell
Current Noise: Enslaved - Reogenesis
To be is to be related.
-- C. J. Keyser.
Reply to: