From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVoDH-0000iY-7Q for qemu-devel@nongnu.org; Sun, 12 Jun 2011 13:12:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVoDF-0002nd-5y for qemu-devel@nongnu.org; Sun, 12 Jun 2011 13:12:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVoDE-0002nX-U3 for qemu-devel@nongnu.org; Sun, 12 Jun 2011 13:12:37 -0400 Message-ID: <4DF4F371.90003@redhat.com> Date: Sun, 12 Jun 2011 20:12:17 +0300 From: Avi Kivity 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> <4DF23BB7.9050606@us.ibm.com> In-Reply-To: <4DF23BB7.9050606@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Anthony Liguori Cc: Peter Maydell , =?ISO-8859-1?Q?Juha_Riihim=E4ki?= , "patches@linaro.org" , Jan Kiszka , "qemu-devel@nongnu.org" , Markus Armbruster , Paul Brook On 06/10/2011 06:43 PM, Anthony Liguori wrote: > >> What exactly is so very wrong about buses that they need to die? > > They force a device tree. The device model shouldn't be a tree, but a > directed graph. Right. As an example, you configure PCI interrupt routing and the memory controller by writing to a PCI device, which logically doesn't have access to any of this stuff if it's behind the PCI bus. However, I don't think buses should die. They should be available as an easy way to model the devices that do follow the rules. But we should also expose everything else for the exceptional cases. > It's perfectly fine to have a type called PCIBus that I440FX extends, > but qdev shouldn't have explicit knowledge of something called a "bus" > IMHO. Doing this forces a limited mechanism of connecting devices > because it creates an artificial tree (by implying a parent/child > relationship). It makes composition difficult if not impossible. I think qdev buses are useful as long as they don't enforce their interfaces. That is, a qdev that is a child of a qbus has access to the qbus's interfaces, but also access to other stuff. That makes the easy devices easy and the hard ones possible. -- error compiling committee.c: too many arguments to function