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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282232421.3170.3195.ca...@zakaz.uk.xensource.com