From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0vUN-0002Tg-Gb for qemu-devel@nongnu.org; Fri, 24 Feb 2012 08:47:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0vUH-0004nI-EQ for qemu-devel@nongnu.org; Fri, 24 Feb 2012 08:47:09 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:41933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0vUH-0004nC-BO for qemu-devel@nongnu.org; Fri, 24 Feb 2012 08:47:05 -0500 Received: by ggni1 with SMTP id i1so1322805ggn.4 for ; Fri, 24 Feb 2012 05:47:04 -0800 (PST) Message-ID: <4F4794D5.7010704@codemonkey.ws> Date: Fri, 24 Feb 2012 07:47:01 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1329347774-23262-1-git-send-email-imammedo@redhat.com> <1329347774-23262-2-git-send-email-imammedo@redhat.com> <4F3CE7A5.30600@siemens.com> <4F3CF9AE.5020701@codemonkey.ws> <4F3E8817.7050001@redhat.com> <4F478B2D.9050903@redhat.com> <4F4790F6.3070301@suse.de> <4F47934C.9080808@redhat.com> In-Reply-To: <4F47934C.9080808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/7] Introduce a new bus "ICC" to connect APIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "qemu-devel@nongnu.org" , Igor Mammedov , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Jan Kiszka On 02/24/2012 07:40 AM, Paolo Bonzini wrote: > On 02/24/2012 02:30 PM, Andreas Färber wrote: >> SysBus is supposed to go away in Anthony's upcoming 4th QOM series, so >> I'd rather not base a new series on that. > > Not sure about that. I haven't understood well the scope of the series, > but I think it only converted buses to QOM, it didn't kill them. > Perhaps SysBus was special, in which case it would become automatically > hotpluggable: just create a new QOM object. > >> The issue with TYPE_DEVICE is that we don't want to leak that into the >> user emulators (would break the build), and any infrastructure only >> available to qdev should gradually be made accessible to all objects >> (Paolo has done some work in that direction wrt properties). > > I haven't, but it would be next on the list of things to do. > >> So the main remaining difference between Object and Device is the >> GPIO IRQ support. Anthony wanted to introduce Pin objects to replace >> qemu_irq. > > Aiming at "replacing" is a bad idea unless you can do it fast and > painlessly. Adding gpio_in and gpio_out property types would be more > useful and would let you expose qemu_irq as QOM. I agree with you in principle, but in practice, there is not obvious way to serialize gpio_in/gpio_out via Visitors. Finding some way to do it as an integer is clearly wrong IMHO. I think a simple Pin object with the following interfaces: /** * Connect a pin to a qemu_irq such that whenever the pin is * raised, qemu_irq_raise() is called too on irq. */ void pin_connect_qemu_irq(Pin *obj, qemu_irq irq); /** * Returns a qemu_irq such that whenever qemu_irq_raise() is * called, pin_set_level(obj, true) is called. */ qemu_irq pin_get_qemu_irq(Pin *obj); Let's you incrementally refactor objects to use Pins while maintaining the existing qemu_irq infrastructure. Regards, Anthony Liguori > You can then change > the existing qdev.c functions to operate on those new property types. > > Paolo