From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrSD2-0003mB-By for qemu-devel@nongnu.org; Sun, 29 Jan 2012 05:42:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrSD0-0006Lj-KD for qemu-devel@nongnu.org; Sun, 29 Jan 2012 05:42:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrSD0-0006Lf-CL for qemu-devel@nongnu.org; Sun, 29 Jan 2012 05:42:06 -0500 Message-ID: <4F252278.4020700@redhat.com> Date: Sun, 29 Jan 2012 12:42:00 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1327604460-31142-1-git-send-email-aliguori@us.ibm.com> <4F21AB32.2090208@codemonkey.ws> In-Reply-To: <4F21AB32.2090208@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 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: Anthony Liguori Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini On 01/26/2012 09:36 PM, Anthony Liguori wrote: > 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. > Like. But note: like a MemoryRegion, a Pin reflects state held elsewhere, so it should not be saved/restored. -- error compiling committee.c: too many arguments to function