From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4cIg-0001UX-5S for qemu-devel@nongnu.org; Fri, 16 Sep 2011 13:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4cIe-0006TM-VO for qemu-devel@nongnu.org; Fri, 16 Sep 2011 13:34:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4cIe-0006St-JS for qemu-devel@nongnu.org; Fri, 16 Sep 2011 13:34:04 -0400 Date: Fri, 16 Sep 2011 19:33:26 +0300 From: Gleb Natapov Message-ID: <20110916163326.GA11160@redhat.com> 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> 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 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. > (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 -- Gleb.