From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55913 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqV7X-0004Yr-IF for qemu-devel@nongnu.org; Thu, 26 Jan 2012 14:36:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqV7S-0005F7-3w for qemu-devel@nongnu.org; Thu, 26 Jan 2012 14:36:30 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:39271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqV7R-0005Eo-VZ for qemu-devel@nongnu.org; Thu, 26 Jan 2012 14:36:26 -0500 Received: by pbdd2 with SMTP id d2so1192196pbd.4 for ; Thu, 26 Jan 2012 11:36:23 -0800 (PST) Message-ID: <4F21AB32.2090208@codemonkey.ws> Date: Thu, 26 Jan 2012 13:36:18 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1327604460-31142-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity , Paolo Bonzini On 01/26/2012 01:12 PM, Peter Maydell wrote: > On 26 January 2012 19:00, Anthony Liguori wrote: >> We need to modeled MemoryRegions and qemu_irq in QOM too. > > +1 : this ought to let us get rid of SysBus... > >> MemoryRegions >> shouldn't be that difficult. Our habit of passing qemu_irq's as arrays without >> an explicit size will probably require some refactoring but in principle, >> supporting irqs should be easy too. > > I think that there are probably a lot of cases where we're using an array > of qemu_irqs now but should be using separately named signals of some sort > instead (particularly where we're using them for things which aren't actually > IRQs...) I started hacking up a Pin object that used a Notifier. It's pretty easy to plumb that to an existing qemu_irq so I think that's the way to go. That way we could incrementally remove qemu_irq usage. I started with this path but the pc initialization was so fubar that I ran into too many problems. Now I think I can go back and do it again and it will be more reasonable given this refactoring. At a high level, a Pin object looks and feels like a qemu_irq. There's a pin_raise, pin_set_level, etc. But there is also a pin_get_level() (it's stateful) and there's a pin_add_level_change_notifier() which allows you to register. Pins are objects so they can be added to the composition tree which means they can be addressed. If you have a truly unidirectional path, then you can just use a child and link and connect them that way. For a bidirectional path (where software controls the direction at run time), you can have an intermediate Wire object which consists of two Pin links. Regards, Anthony Liguori > > -- PMM >