From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6pg-0002P2-KC for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:19:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm6pb-0000WF-Sz for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:19:40 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:53232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6pb-0000W3-P9 for qemu-devel@nongnu.org; Wed, 27 Jul 2011 12:19:35 -0400 Received: by yxt3 with SMTP id 3so1075829yxt.4 for ; Wed, 27 Jul 2011 09:19:35 -0700 (PDT) Message-ID: <4E303A94.8060208@codemonkey.ws> Date: Wed, 27 Jul 2011 11:19:32 -0500 From: Anthony Liguori 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> In-Reply-To: <4E302FBF.4040500@redhat.com> 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: Paolo Bonzini Cc: Peter Maydell , qemu-devel@nongnu.org On 07/27/2011 10:33 AM, Paolo Bonzini wrote: > 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. Sounds like I need to read a little about how this enumerator works. I can't see how this would all operate without the enumerating being some form of a bus. > >> At each phase, we also get significantly better modularity. > > Fine, but when do we decide it's good enough to merge it? I think we should evaluate the complexity vs. value trade off with the character device layer (when fully converted) and make the decision in a vacuum. If the complexity seems too high, I can try to also convert the block layer and we can reevaluate. I believe that just with the character device layer, it's a net win and I don't think it can be dramatically simplified. The patches are actually not a lot of code. The only complexity is conceptual and that's because it takes into account a lot of different problems. I can even pair things down a bit by removing support for Interfaces and simplifying class initialization of need be for the first merge. > 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). I tried to use GObject btw, I can share the results with you if you'd like. Even with backends, I couldn't make properties work. GObject uses GValues for properties which roughly models immutable values in a variant. But I couldn't find a reasonable way to express Plugs and Sockets in terms of GValues. I expect that at some point in the future, GObject will grow GVariant properties. But I still think GVariant isn't quite what it needs to be since it still assumes immutable variants that can be copied. I thought about just using GType but I thought using GType without using GObject was probably not a great long term plan as I doubt anyone else does this. Regards, Anthony Liguori > >> 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 >