From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4cpz-0005Qg-Hx for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:08:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4cpy-0006eL-6d for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:08:31 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:49679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4cpy-0006e7-1g for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:08:30 -0400 Received: by gwj20 with SMTP id 20so4071052gwj.12 for ; Fri, 16 Sep 2011 11:08:29 -0700 (PDT) Message-ID: <4E73909B.3050900@codemonkey.ws> Date: Fri, 16 Sep 2011 13:08:27 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <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> <20110916163326.GA11160@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/16/2011 12:47 PM, 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). > > 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. Exactly. This is what I dislike about qdev today. The UART (SerialState) is not a DeviceState. That's a major problem for me. There should be no different between IsaSerialState and SerialState in terms of what they are and how you interact with them. Whether IsaSerialState should even exist is a separate discussion that's really just a minor detail. Regards, Anthony Liguori > > 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. > > -- PMM >