From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4JHK-0003XY-C4 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 17:15:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4JHJ-0007Kw-3T for qemu-devel@nongnu.org; Thu, 15 Sep 2011 17:15:26 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:65106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4JHI-0007Kr-W6 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 17:15:25 -0400 Received: by gwj20 with SMTP id 20so3150553gwj.12 for ; Thu, 15 Sep 2011 14:15:24 -0700 (PDT) Message-ID: <4E726AE9.1040905@codemonkey.ws> Date: Thu, 15 Sep 2011 16:15:21 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E720435.3060509@codemonkey.ws> <4E720855.1090501@redhat.com> <20110915142534.GC11524@redhat.com> <4E7219B4.9050109@us.ibm.com> <20110915153838.GE11524@redhat.com> <4E7228BC.9030104@us.ibm.com> <20110915165921.GF11524@redhat.com> <4E723B1B.5070805@codemonkey.ws> <20110915202907.GG11524@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Gleb Natapov , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" , Paolo Bonzini On 09/15/2011 03:45 PM, Peter Maydell wrote: > On 15 September 2011 21:29, Gleb Natapov wrote: >> 16650A is not a device. ISA card it resides on is a device. > > The 16550A is an encapsulated set of functionality with some > well defined interfaces ("I provide a set of memory mapped > registers", "I have an output gpio line (irq)"), which we > need to be able to compose into other things (lots of models > use a 16550A one way or another, not just the ISA serial card), > connect up (ie connect that irq to an appropriate interrupt > controller, map the registers in system memory or under ISA > or whatever), and configure (eg specify the backend chardev). Absolutely. My view of a "bus" has always been that it's just a well defined set of connectors. Inheritance becomes a useful way of obtaining that well defined set of connectors. So: /i440fx/slot[3] = my-e1000 Is really just short-hand for: /i440fx/slot[3]-bar[0] = my-e1000.bar[0] /i440fx/slot[3]-bar[1] = my-e1000.bar[1] ... And more specifically, my thinking was that you could basically omit the explicit use of connectors when using a Bus for the sake of convenience. So there's no real need for my-e1000 to actively publish bar[0], bar[1]. I think that later point is where you object most and it's also the area that I'm the least convinced myself so I'm pretty open there. Regards, Anthony Liguori > I don't think there's any difference at all between that > and (say) the NE2000 PCI model, which also is encapsulated > functionality with well defined interfaces that we need to > be able to compose and connect and configure. We should be > using the same implementation and abstractions for both > cases. > > (Note the analogy to hardware: a 16550A chip is a well > specified encapsulated set of functionality with some > electrical, timing, etc restrictions on its use. The > only difference between that and an ISA card is that the > ISA card happens to be physically manufactured so that an > end user can plug it, unplug it and wave it around.) > > -- PMM >