From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJOh-0001HO-JS for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:14:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiJOd-0003h0-Cd for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:14:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJOd-0003gW-7A for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:14:11 -0400 Date: Wed, 15 Apr 2015 11:14:01 +0200 From: Thomas Huth Message-ID: <20150415111401.4e3865fd@thh440s> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] PING - add 1394 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Itamar Tal Cc: qemu-devel@nongnu.org, Pavel Gurvich , kraxel@redhat.com Am Tue, 7 Apr 2015 11:18:41 +0300 schrieb Itamar Tal : > Hi, > > Haven't got any response to this patch and couldn't find relevant > maintainer as well. Can anyone direct me to the right guy? > > Thanks, > > Itamar Tal, > Guardicore > > On Mon, Mar 23, 2015 at 6:07 PM, Itamar Tal wrote: > > > From 9c4425d4145ac6b0a2d19a6fdf5803dd13f1fa93 Mon Sep 17 00:00:00 2001 > > From: Itamar Tal > > Date: Mon, 23 Mar 2015 14:26:47 +0200 > > Subject: [PATCH] add 1394 support > > > > This patch add 1394 (firewire) support to x86_64 and i386 qemu > > softmmu. It allows one virtual machine to be the server side and the > > other to be the client side, connected by TCP stream socket (same > > thing is possible using serial port). This is very useful in for > > allowing legacy devices to communicate over the firewire channel, but > > doesn't support USB communication. Especially, it's useful for remote > > Windows kernel debugging over qemu for malware analysis and so on... > > The patch was tested on major stable version 2.0.0, 2.2.1 and current > > master (2.3.0rc?). > > > > Itamar Tal, > > Guardicore > > > > --- > > hw/1394/Makefile.objs | 7 + > > hw/1394/hcd-ohci.c | 1645 > > +++++++++++++++++++++++++++++++++++++++++++++++++ > > hw/1394/hcd-ohci.h | 147 +++++ > > hw/Makefile.objs | 1 + > > 4 files changed, 1800 insertions(+) > > create mode 100644 hw/1394/Makefile.objs > > create mode 100644 hw/1394/hcd-ohci.c > > create mode 100644 hw/1394/hcd-ohci.h > > > > diff --git a/hw/1394/Makefile.objs b/hw/1394/Makefile.objs > > new file mode 100644 > > index 0000000..6c039e6 > > --- /dev/null > > +++ b/hw/1394/Makefile.objs > > @@ -0,0 +1,7 @@ > > +ifeq ($(TARGET_X86_64),y) > > +common-obj-y += hcd-ohci.o > > +else > > +ifeq ($(TARGET_I386),y) > > +common-obj-y += hcd-ohci.o > > +endif > > +endif That's quite a cumbersome way of adding a new bus controller - especially since firewire could be useful for other architectures, too. Could you maybe rather add a proper CONFIG_1394_OHCI (or something similar) option to default-configs/x86_64-softmmu.mak and i386-softmmu.mak instead and then simply do a common-obj-$(CONFIG_1394_OHCI) += hcd-ohci.o here? Thomas