swiotlb-xen tree + xen + linux-next

PATCH Konrad Rzeszutek Wilk 2 participants 2 messages Oct 19, 2010

Subsystems (2)

Linux-next tree PCI

lore

Share & tools

lore

Konrad Rzeszutek Wilk

author

2010-10-19 14:25 UTC #0 lore raw

Hey Stephen,

Jeremy and I fixed the mega failures you saw and last night Jeremy's got pulled in while mine was silent. I am enabling my tree today, and while the previous failure is gone when I do a merge of my tree against linux-next, I keep on getting one that I am having trouble solving.

The issues is that my patchset touches drivers/pci/Makefile which had been changed a bit by a): 350a55e9ff6005032407d3234af800f413b03af5 (PCI: use new ccflags variable in Makefile) which does this:
@@ -65,6 +65,4 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o

obj-$(CONFIG_PCI_STUB) += pci-stub.o

-ifeq ($(CONFIG_PCI_DEBUG),y)
-EXTRA_CFLAGS += -DDEBUG
-endif
+ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

And then b) my patch (git commit 956a9202cd1220397933a07beda9f96b3df1fa24
xen-pcifront: Xen PCI frontend driver.) goes in and tries to add:

@@ -65,6 +65,8 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o

obj-$(CONFIG_PCI_STUB) += pci-stub.o

+obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o +
ifeq ($(CONFIG_PCI_DEBUG),y)
EXTRA_CFLAGS += -DDEBUG
endif

I've tried to put a) patch in the branch and rebase my tree on top of that and this way, the "ifeq ($(CONFIG_PCI_DEBUG_...)" is gone, but merge still complains! The error is:

drivers/pci/Makefile +0 -0

diff --cc drivers/pci/Makefile
index dcd7ace,39c7327..0000000
@@@ -65,4 -65,7 +65,10 @@@ obj-$(CONFIG_PCI_SYSCALL) += syscall.
  
  obj-$(CONFIG_PCI_STUB) += pci-stub.o
  
++<<<<<<< HEAD
++=======
+ # Xen PCI frontend driver
+ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+ 
++>>>>>>> stable/xen-pcifront-0.8.3
  ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

[That branch with the a) patch is stable/xen-pcifront-0.8.3, which differs from #linux-next (which is linked to stable/xen-pcifront-0.8.2) by just having the patch a) in it. I am not going to use that for #linux-next as it does not seem to make merging automatic].

Any ideas why it is doing this?

In the internim and so that the merge tonight won't be broken, I've attached a merge conflict patch instead:

drivers/pci/Makefile +2 -0

index dcd7ace..f01e344 100644
@@ -65,4 +65,6 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o
 
 obj-$(CONFIG_PCI_STUB) += pci-stub.o
 
+obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+
 ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

Stephen Rothwell

2010-10-19 14:59 UTC #1 lore raw

Hi Konrad,

Quoted 5 lines · On Tue, 19 Oct 2010 10:25:39 -0400 Konrad Rzeszutek Wilk…

Jeremy and I fixed the mega failures you saw and last night Jeremy's got pulled in while mine was silent. I am enabling my tree today, and while the previous failure is gone when I do a merge of my tree against linux-next, I keep on getting one that I am having trouble solving.

Thanks for fixing this all up.

Quoted 45 lines

The issues is that my patchset touches drivers/pci/Makefile which had been changed a bit by a): 350a55e9ff6005032407d3234af800f413b03af5 (PCI: use new ccflags variable in Makefile) which does this:
(quoted diff) +1 -3
@@ -65,6 +65,4 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o
 
 obj-$(CONFIG_PCI_STUB) += pci-stub.o
 
-ifeq ($(CONFIG_PCI_DEBUG),y)
-EXTRA_CFLAGS += -DDEBUG
-endif
+ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
And then b) my patch (git commit 956a9202cd1220397933a07beda9f96b3df1fa24
xen-pcifront: Xen PCI frontend driver.) goes in and tries to add:
drivers/pci/Makefile +2 -0
@@ -65,6 +65,8 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o
 
 obj-$(CONFIG_PCI_STUB) += pci-stub.o
 
+obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+
 ifeq ($(CONFIG_PCI_DEBUG),y)
 EXTRA_CFLAGS += -DDEBUG
 endif
I've tried to put a) patch in the branch and rebase my tree on top of that and this way, the "ifeq ($(CONFIG_PCI_DEBUG_...)" is gone, but merge still complains! The error is:
drivers/pci/Makefile +6 -0
diff --cc drivers/pci/Makefile
index dcd7ace,39c7327..0000000
@@@ -65,4 -65,7 +65,10 @@@ obj-$(CONFIG_PCI_SYSCALL) += syscall.
 
  obj-$(CONFIG_PCI_STUB) += pci-stub.o
 
++<<<<<<< HEAD
++=======
+ # Xen PCI frontend driver
+ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+ 
++>>>>>>> stable/xen-pcifront-0.8.3
  ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

Quoted 6 lines

[That branch with the a) patch is stable/xen-pcifront-0.8.3, which differs from #linux-next (which is linked to stable/xen-pcifront-0.8.2) by just having the patch a) in it. I am not going to use that for #linux-next as it does not seem to make merging automatic].
Any ideas why it is doing this?

I think that if git sees this as the "ccflags" change on one side of the merge and "ccflags" change plus your change on the other and decides that it conflicts. It considers the two "ccflags" changes to be different because they are not the same commit (even if they have the same patch).

Quoted 9 lines

In the internim and so that the merge tonight won't be broken, I've attached a merge conflict patch instead:
drivers/pci/Makefile +0 -0
index dcd7ace..f01e344 100644

drivers/pci/Makefile obj-$(CONFIG_PCI_SYSCALL) += syscall.o · line 70

Quoted 6 lines

drivers/pci/Makefile +2 -0

@@ -65,4 +65,6 @@ obj-$(CONFIG_PCI_SYSCALL) += syscall.o
 
 obj-$(CONFIG_PCI_STUB) += pci-stub.o
 
+obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o
+
 ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

Thanks. You don't need to worry about simple conflicts like this, Linus and I are both quite happy with fixing them up - though I will still report them, just so people know what is going on.

Signature · 3 lines

Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/