From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmTQr-0001e8-Be for qemu-devel@nongnu.org; Thu, 28 Jul 2011 12:27:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmTQq-0000gy-Ai for qemu-devel@nongnu.org; Thu, 28 Jul 2011 12:27:33 -0400 Received: from mail-ww0-f53.google.com ([74.125.82.53]:64545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmTQq-0000gm-5Y for qemu-devel@nongnu.org; Thu, 28 Jul 2011 12:27:32 -0400 Received: by wwf26 with SMTP id 26so2407128wwf.10 for ; Thu, 28 Jul 2011 09:27:31 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E318482.9030806@redhat.com> Date: Thu, 28 Jul 2011 17:47:14 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <4E2EBA1E.90006@redhat.com> <4E2EC90E.8090409@codemonkey.ws> <4E2ED0AA.3020101@redhat.com> <4E2EDE86.7020807@codemonkey.ws> <4E2F06C8.30403@redhat.com> <4E2F1448.3040106@codemonkey.ws> <4E2FD28F.2070206@redhat.com> <4E30091C.3070404@codemonkey.ws> <4E302FBF.4040500@redhat.com> <4E303CBF.8070801@codemonkey.ws> <4E305E3F.2050405@redhat.com> <4E306EA5.5020207@codemonkey.ws> <4E311160.8060506@redhat.com> <4E315A3F.90804@codemonkey.ws> <4E316924.8020001@redhat.com> <4E316C36.1050405@codemonkey.ws> <4E317514.30505@redhat.com> <4E317A96.7000604@codemonkey.ws> In-Reply-To: <4E317A96.7000604@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org On 07/28/2011 05:04 PM, Anthony Liguori wrote: > The only way I can see is to teach each device about this interface and > then have a common bus. That implies that you have: > > class GoldfishEnumerator : public Device { > GoldfishDevice *slots[N]; FWIW, there's no hardcoded limit in the interface, and the list of devices is unordered. But that only means you should attach it with plug-set goldfish_tty::enumerator goldfish_enum rather than plug-set goldfish_enum::slots[12] goldfish_tty If you can confirm that, that's fine. > }; > > interface GoldfishDevice { > const char *get_name(); > uint64_t get_mmio_base(); > ... > }; > > class GoldfishNic : public Device, implements GoldfishDevice > { > const char *get_name(void) { > return "nic"; > } uint64_t mmio_base; uint64_t get_mmio_base() { return mmio_base; } uint64_t set_mmio_base(uint64_t addr) { mmio_base = addr; } > }; And that's exactly my point. It's a "stupid" interface full of getters/setters, which is what you get if you use only interface inheritance instead of, where appropriate, data containment. Interfaces should be reserved for what really depends on the _implementation_ of the GoldfishNic, not for accessing a bunch of numbers. There is no implementation-dependent detail of that kind in the GoldfishDevice (unlike other buses, even simple ones like I2C). >> The PIC's view is more complicated than a Pin, and more similar to ISA. > > ISA is just a pin. The ISA bus extender literally has five pins > corresponding to the ISA IRQs 7, 6, 5, 4, 3. ISA is many pins. :) Goldfish looks similar (32 pins). Paolo