Re: [Qemu-devel] [PATCH] Makefile.target: include top level build dir in vpath

2015-09-07 Thread Michael Marineau
On Sun, Aug 23, 2015 at 5:57 PM, Michael Marineau
<michael.marin...@coreos.com> wrote:
> Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
> rewrite all absolute paths to relative paths. This interacts poorly with
> QEMU's two-level build directory scheme. For example, lets say
> BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:
>
>   blockdev.o: ../blockdev.c ../include/sysemu/block-backend.h \
>
> Now the target build under build/x86_64-softmmu or similar will depend
> on ../blockdev.o which in turn will get make to source ../blockdev.d to
> check its dependencies. Since make always considers paths relative to
> the current working directory rather than the makefile the path appeared
> in the relative path to ../blockdev.c is useless.
>
> This change simply adds the top level build directory to vpath so paths
> relative to the source directory, top build directory, and target build
> directory all work just fine.
>
> Signed-off-by: Michael Marineau <michael.marin...@coreos.com>
> ---
>
> This is a re-send with the proper Signed-off-by line.
>
>  Makefile.target | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.target b/Makefile.target
> index 3e7aafd..dc32294 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -7,7 +7,7 @@ include config-target.mak
>  include config-devices.mak
>  include $(SRC_PATH)/rules.mak
>
> -$(call set-vpath, $(SRC_PATH))
> +$(call set-vpath, $(SRC_PATH):$(BUILD_DIR))
>  ifdef CONFIG_LINUX
>  QEMU_CFLAGS += -I../linux-headers
>  endif
> --
> 2.4.6
>

ping http://patchwork.ozlabs.org/patch/510065/



Re: [Qemu-devel] [PATCH] Makefile.target: include top level build dir in vpath

2015-09-07 Thread Michael Marineau
On Mon, Sep 7, 2015 at 2:11 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 07/09/2015 23:02, Michael Marineau wrote:
>> ping http://patchwork.ozlabs.org/patch/510065/
>
> Just back from vacation, this is queued in my next pull request
> (currently at tags/for-upstream on github.com/bonzini/qemu.git, but I
> haven't finished testing it).
>
> Paolo

Great, thanks!



[Qemu-devel] [PATCH] Makefile.target: include top level build dir in vpath

2015-08-24 Thread Michael Marineau
Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
rewrite all absolute paths to relative paths. This interacts poorly with
QEMU's two-level build directory scheme. For example, lets say
BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:

  blockdev.o: ../blockdev.c ../include/sysemu/block-backend.h \

Now the target build under build/x86_64-softmmu or similar will depend
on ../blockdev.o which in turn will get make to source ../blockdev.d to
check its dependencies. Since make always considers paths relative to
the current working directory rather than the makefile the path appeared
in the relative path to ../blockdev.c is useless.

This change simply adds the top level build directory to vpath so paths
relative to the source directory, top build directory, and target build
directory all work just fine.

Signed-off-by: Michael Marineau michael.marin...@coreos.com
---

This is a re-send with the proper Signed-off-by line.

 Makefile.target | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.target b/Makefile.target
index 3e7aafd..dc32294 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -7,7 +7,7 @@ include config-target.mak
 include config-devices.mak
 include $(SRC_PATH)/rules.mak
 
-$(call set-vpath, $(SRC_PATH))
+$(call set-vpath, $(SRC_PATH):$(BUILD_DIR))
 ifdef CONFIG_LINUX
 QEMU_CFLAGS += -I../linux-headers
 endif
-- 
2.4.6




Re: [Qemu-devel] [PATCH] Makefile.target: include top level build dir in vpath

2015-08-12 Thread Michael Marineau
On Aug 12, 2015 6:32 AM, Paolo Bonzini pbonz...@redhat.com wrote:



 On 09/08/2015 09:02, Michael Marineau wrote:
  Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
  rewrite all absolute paths to relative paths. This interacts poorly with
  QEMU's two-level build directory scheme. For example, lets say
  BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:
 
blockdev.o: ../blockdev.c ../include/sysemu/block-backend.h \
 
  Now the target build under build/x86_64-softmmu or similar will depend
  on ../blockdev.o which in turn will get make to source ../blockdev.d to
  check its dependencies. Since make always considers paths relative to
  the current working directory rather than the makefile the path appeared
  in the relative path to ../blockdev.c is useless.
 
  This change simply adds the top level build directory to vpath so paths
  relative to the source directory, top build directory, and target build
  directory all work just fine.
  ---
   Makefile.target | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/Makefile.target b/Makefile.target
  index 3e7aafd..dc32294 100644
  --- a/Makefile.target
  +++ b/Makefile.target
  @@ -7,7 +7,7 @@ include config-target.mak
   include config-devices.mak
   include $(SRC_PATH)/rules.mak
 
  -$(call set-vpath, $(SRC_PATH))
  +$(call set-vpath, $(SRC_PATH):$(BUILD_DIR))
   ifdef CONFIG_LINUX
   QEMU_CFLAGS += -I../linux-headers
   endif
 

 Hi,

 can you reply with Signed-off-by: Michael Marineau
 michael.marin...@coreos.com, representing that you've read and agreed
 to the Developer Certificate of Origin (http://developercertificate.org/)?

 This is necessary to include your patch in QEMU.

 Paolo

Oops, forgot about that.

Signed-off-by: Michael Marineau
michael.marin...@coreos.com


[Qemu-devel] [PATCH] Makefile.target: include top level build dir in vpath

2015-08-09 Thread Michael Marineau
Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
rewrite all absolute paths to relative paths. This interacts poorly with
QEMU's two-level build directory scheme. For example, lets say
BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:

  blockdev.o: ../blockdev.c ../include/sysemu/block-backend.h \

Now the target build under build/x86_64-softmmu or similar will depend
on ../blockdev.o which in turn will get make to source ../blockdev.d to
check its dependencies. Since make always considers paths relative to
the current working directory rather than the makefile the path appeared
in the relative path to ../blockdev.c is useless.

This change simply adds the top level build directory to vpath so paths
relative to the source directory, top build directory, and target build
directory all work just fine.
---
 Makefile.target | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.target b/Makefile.target
index 3e7aafd..dc32294 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -7,7 +7,7 @@ include config-target.mak
 include config-devices.mak
 include $(SRC_PATH)/rules.mak
 
-$(call set-vpath, $(SRC_PATH))
+$(call set-vpath, $(SRC_PATH):$(BUILD_DIR))
 ifdef CONFIG_LINUX
 QEMU_CFLAGS += -I../linux-headers
 endif
-- 
2.4.6




Re: [Qemu-devel] [PATCH] Fix usage of USB_DEV_FLAG_IS_HOST flag.

2013-05-21 Thread Michael Marineau
On Mon, May 13, 2013 at 11:51 AM, Gerd Hoffmann kra...@redhat.com wrote:

 On 05/13/13 01:19, Michael Marineau wrote:
  USB_DEV_FLAG_IS_HOST is the bit number, not value. Booting with a
  Fitbit Base Station USB dongle was triggering this assert.
 
  Signed-off-by: Michael Marineau m...@marineau.org
  ---
   hw/usb/core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/hw/usb/core.c b/hw/usb/core.c
  index 15a150a..05948ca 100644
  --- a/hw/usb/core.c
  +++ b/hw/usb/core.c
  @@ -410,7 +410,7 @@ void usb_handle_packet(USBDevice *dev, USBPacket *p)
   assert(p-ep-type != USB_ENDPOINT_XFER_ISOC);
   /* using async for interrupt packets breaks migration */
   assert(p-ep-type != USB_ENDPOINT_XFER_INT ||
  -   (dev-flags  USB_DEV_FLAG_IS_HOST));
  +   (dev-flags  (1  USB_DEV_FLAG_IS_HOST)));
   usb_packet_set_state(p, USB_PACKET_ASYNC);
   QTAILQ_INSERT_TAIL(p-ep-queue, p, queue);
   } else if (p-status == USB_RET_ADD_TO_QUEUE) {

 Looks good.

 Anthony?  Can you pick it for 1.5 directly?  I don't have any other
 pending usb bits for 1.5 at the moment.

 Reviewed-by: Gerd Hoffmann kra...@redhat.com

 cheers,
   Gerd


Ping, looks like this hasn't managed to land in master yet and just wanted
to make sure it doesn't get forgotten. I probably should have noted in the
original email that this bug was introduced
in be41efde3ca0372dbf7543e09ff473b4eec25057 and impacts both 1.4 and 1.5.

-- 
Michael Marineau


[Qemu-devel] [PATCH] Fix usage of USB_DEV_FLAG_IS_HOST flag.

2013-05-12 Thread Michael Marineau
USB_DEV_FLAG_IS_HOST is the bit number, not value. Booting with a
Fitbit Base Station USB dongle was triggering this assert.

Signed-off-by: Michael Marineau m...@marineau.org
---
 hw/usb/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/core.c b/hw/usb/core.c
index 15a150a..05948ca 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -410,7 +410,7 @@ void usb_handle_packet(USBDevice *dev, USBPacket *p)
 assert(p-ep-type != USB_ENDPOINT_XFER_ISOC);
 /* using async for interrupt packets breaks migration */
 assert(p-ep-type != USB_ENDPOINT_XFER_INT ||
-   (dev-flags  USB_DEV_FLAG_IS_HOST));
+   (dev-flags  (1  USB_DEV_FLAG_IS_HOST)));
 usb_packet_set_state(p, USB_PACKET_ASYNC);
 QTAILQ_INSERT_TAIL(p-ep-queue, p, queue);
 } else if (p-status == USB_RET_ADD_TO_QUEUE) {
-- 
1.8.1.2