From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4czs-0007wX-CP for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:18:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4czr-0001qi-DK for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:18:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4czr-0001qW-6A for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:18:43 -0400 Date: Fri, 16 Sep 2011 21:18:37 +0300 From: Gleb Natapov Message-ID: <20110916181837.GC11160@redhat.com> References: <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> <20110916163326.GA11160@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , Paolo Bonzini , "Edgar E. Iglesias" On Fri, Sep 16, 2011 at 06:47:56PM +0100, Peter Maydell wrote: > On 16 September 2011 17:33, Gleb Natapov wrote: > > On Thu, Sep 15, 2011 at 09:45:33PM +0100, 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). > >> > >> 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. > >> > > IDE is another such device (it was ISA later converted to PCI). > > As far as I understand your view of UART is the same as mine. > > It is not a whole device, but only a part of it. > > If we have the same view of the UART then one of us is rather > misunderstanding the other (could be me). > May be. > I don't care whether you apply the label "device" to the > UART, but I definitely want it to be exactly the same kind > of QEMU "object", in terms of how you implement it and use it, > as a PCI NE2000 model or an ISA serial card or an ARM-Cortex-A8 > CPU model or a "vexpress-a9" board model. > > As it happens, personally I think "device" is a pretty > reasonable label to use for all these things, since we're going > to use it anyway for the QEMU objects which happen to correspond > to ISA cards or PCI cards or whatever. > I am not arguing with that. The argument is about what devices hierarchy in QMEU should be, not what to call "device" and what not to. -- Gleb.