From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sczj5-0003yD-OO for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:59:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scziy-0007na-VU for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:59:43 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:60685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scziy-0007nL-Ph for qemu-devel@nongnu.org; Fri, 08 Jun 2012 09:59:36 -0400 From: Paul Brook Date: Fri, 8 Jun 2012 14:59:31 +0100 References: <201206081413.26378.paul@codesourcery.com> <4FD2008C.1020908@us.ibm.com> In-Reply-To: <4FD2008C.1020908@us.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201206081459.32169.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: Anthony Liguori Cc: Peter Maydell , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , "Edgar E. Iglesias" , Andreas =?utf-8?q?F=C3=A4rber?= , John Williams > >>> 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)? > 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? Paul