From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SczPq-0003y3-0N for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:39:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SczPj-0003LR-Ij for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:39:49 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:58592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SczPj-0003KJ-0p for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:39:43 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 8 Jun 2012 13:36:32 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q58DWBdA61145314 for ; Fri, 8 Jun 2012 23:32:11 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q58DdWqo011664 for ; Fri, 8 Jun 2012 23:39:33 +1000 Message-ID: <4FD2008C.1020908@us.ibm.com> Date: Fri, 08 Jun 2012 21:39:24 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <201206081013.09756.paul@codesourcery.com> <201206081413.26378.paul@codesourcery.com> In-Reply-To: <201206081413.26378.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Peter Maydell , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , John Williams On 06/08/2012 09:13 PM, Paul Brook wrote: >> On 8 June 2012 10:13, Paul Brook wrote: >>> Of course we then hit the usual problem with QOM that we can only link to >>> objects, and it's impossible to expose multiple interfaces of the same >>> type. >> >> I'm pretty sure Anthony claimed this was entirely possible -- >> presumably that's how Pins are going to work. > > Really? Every time I've talked to him I've got the opposite impression. Part > of the response has been that interrupt pins are the only case where this > actually occurs, so It's not worth fixing properly. I think it depends on your definition of "properly". There's really only three concepts in QOM that matter for this discussion: 1) objects 2) children and 3) links. There is absolutely no difference between a Pin object and a SerialState object. They both are first-class objects are far as QOM and concerned. Both can have links to other objects. The most common way for other objects to create objects is via children. A device could have a bunch of Pin child objects with that being the sole communication mechanism with the outside world. A device could also have a 'PCISocket' child object (which inherits from PCIDevice) in order to expose a PCI interface to the world. For most bus-based devices, I think the above is poor design. But that's my opinion from a modeling PoV, QOM doesn't have an opinion from an infrastructure PoV. > I disagree with this > assesment. > > Given we do need to expose multiple instances of the same interface, I see a > few different options: > > - Create a proxy object for each reciever which multiplexes onto a different > interface on the main object. For interrupt pins this basically means making > the qemu_irq object part of the device tree, and have the actual device > implement qemu_irq_handler (see hw/irq.h). The equivalent of qemu_irq (i.e. > irq.c/h) needs to be created for every duplicated interface. It's worth > noting that qemu_irq is about as simple as it gets, it's a single > unidirectional call. > > - Make some form of handle an explicit part of the API. IMO this is a really > bad idea, and a step backwards. In the qemu_irq case it means that the device > raising the interrupt needs to know how the interrupt controller enumerates > its input pins, and which one it's connected to. Instead of making > connections via a nice clean links we have a link and some other device > specific information. It's worse than the old callback+opaque pointer pair > because user [machine description] has to provide that device specific > additional value. > > - Link to properties, not objects. This probably ends up similar to the first > option, except with a framework and consistent implementation across different > interfaces. Let me read and respond to the rest of the thread. I'm not sure a super abstract discussion here is going to be helpful Regards, Anthony Liguori > > Paul >