From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm66y-0008PJ-JM for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:33:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm66t-00060r-Il for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:33:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm66t-00060h-BV for qemu-devel@nongnu.org; Wed, 27 Jul 2011 11:33:23 -0400 Message-ID: <4E302FBF.4040500@redhat.com> Date: Wed, 27 Jul 2011 17:33:19 +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> In-Reply-To: <4E30091C.3070404@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/27/2011 02:48 PM, Anthony Liguori wrote: > > So the idea here is that the PIC will multiplex a bunch of interrupts > into a single line? Yes, but the device needs to know the interrupt number so it can expose it through the enumerator interface. So the configuration cannot be simply pic->irq[n] = tty->irq; Logically, it's more similar to the ISA case, but I doubt the PIC distributes all interrupts to everyone in real hardware. > Is the enumerator something that has an interface to devices where > the devices hold this info? Or is the enumerator just a bank of > flash that's preprogrammed with fixed info? The former, at least in theory. Not sure if it also works that way in real hardware, but that's the model it exposes and the way the Android guys implemented it. The device model provides hotplug support, so it is definitely not just flash. Not sure again if this support is used in the hardware. > At each phase, we also get significantly better modularity. Fine, but when do we decide it's good enough to merge it? And what if it turns out that it's not suitable for devices? We unified some things, but we also dug ourselves in NIH when we could have used GObject. (GObject definitely does not work for devices, but at least we don't need to write the infrastructure). > My only real concern is how to attack the device layer incrementally. > I don't think it's impossible but it requires careful thought. No idea here, honestly. :) Paolo