From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scz0a-0003Gd-HW for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:13:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scz0T-0005gC-9W for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:13:44 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:54753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scz0T-0005fv-46 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:13:37 -0400 From: Paul Brook Date: Fri, 8 Jun 2012 14:13:24 +0100 References: <201206081013.09756.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206081413.26378.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Michal Simek , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , "Edgar E. Iglesias" , Andreas =?utf-8?q?F=C3=A4rber?= , John Williams > 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 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. Paul