From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sd00g-0003br-Oh for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:17:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sd00e-0004Ct-Iu for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:17:54 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:39955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sd00e-0004CE-C9 for qemu-devel@nongnu.org; Fri, 08 Jun 2012 10:17:52 -0400 Received: by dadv2 with SMTP id v2so2667063dad.4 for ; Fri, 08 Jun 2012 07:17:50 -0700 (PDT) Message-ID: <4FD20988.4020509@codemonkey.ws> Date: Fri, 08 Jun 2012 22:17:44 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <201206081413.26378.paul@codesourcery.com> <4FD2008C.1020908@us.ibm.com> <201206081459.32169.paul@codesourcery.com> In-Reply-To: <201206081459.32169.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 , Anthony Liguori , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , John Williams On 06/08/2012 09:59 PM, 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. > > And those pin objects would presumably communicate back to the device via some > as-yet unimplemented PinMultiplex interface link? Or are you expecting the > Pin objects to have an API call that allows the device to register an > arbitrary QEMUBH (or equivalent)? Notifiers actually. The rough model is Signal/Slots similar to GObject and/or QT. > >> 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. > > So what is a good design? Are you hoping most of your interfaces are > stateless, so can be implemented directly on the device object? QOM is not a panacea. We still need to have good objects/interfaces. For this specific example, it sounds like a job for the DMA API dwg/benh have proposed. I responded with more detail in another part of the thread. Regards, Anthony Liguori > > Paul >