From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV2nz-0001rz-6U for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:35:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QV2nx-0002HL-AR for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:35:22 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:37845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QV2nw-0002HF-V8 for qemu-devel@nongnu.org; Fri, 10 Jun 2011 10:35:21 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5AEMYY1015295 for ; Fri, 10 Jun 2011 08:22:34 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p5AEYuxx029862 for ; Fri, 10 Jun 2011 08:35:01 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5A8YWwV013819 for ; Fri, 10 Jun 2011 02:34:33 -0600 Message-ID: <4DF22B77.5030703@us.ibm.com> Date: Fri, 10 Jun 2011 09:34:31 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1307532813-27175-1-git-send-email-peter.maydell@linaro.org> <4DEF6B2B.7090305@siemens.com> <4DF0FCDA.5070804@siemens.com> <4DF21334.2070204@us.ibm.com> <4DF21F97.4070709@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?SnVoYSBSaWloaW3DpGtp?= , "patches@linaro.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Markus Armbruster , Paul Brook On 06/10/2011 08:50 AM, Peter Maydell wrote: > On 10 June 2011 14:43, Jan Kiszka wrote: >> On 2011-06-10 15:10, Peter Maydell wrote: >>> This makes the wiring of this signal look like a property of the >>> isa-serial device, which is a bit odd, since it's just as much >>> a property of the piix3. Actually it's neither, it's a property >>> of the machine model, and you might actually want a syntax a bit >>> more like: >>> >>> piix3 = piix3(property=value, property=value...); >>> serial = isa-serial(property=value...); >>> connect(serial.irq, piix3.irq[3]); >> >> In fact, in the ISA case, it is a device property: The device, and only >> the device decides which IRQ to use - from the bus it is attached to. So >> attaching an ISA device to the bus of an ISA bridge like the PIIX3 and >> selecting local IRQ 3 are the steps we can already express today. > > Ah, in that case Anthony's suggestion of > -device piix3,id=piix3 -device isa-serial,id=serial,irq=piix3.irq[3] > wrong in a different way -- the isa-serial shouldn't care > what other device is providing the ISA bus it is sitting on, If it really makes you feel bad, you could also do: -device piix3,id=piix3 -device wire,id=wire,in=piix3.irq[3] -device isa-serial,id=serial,irq=wire.out Regards, Anthony Liguori > it just has a property of which ISA irq line it is using > (and rely on an isa bus abstraction to wire things up at > the machine model level). [As you say, this works now.] > > But I think that's a non-typical case compared to the usual one > of "these wires are just hardwired this way by the machine". > > -- PMM