From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEB4-0001aY-4i for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:13:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScEAz-0006y1-E7 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:13:25 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:58005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEAz-0006xL-B6 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:13:21 -0400 Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Jun 2012 07:13:16 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 359896E8049 for ; Wed, 6 Jun 2012 07:12:15 -0400 (EDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q56BCEwZ096654 for ; Wed, 6 Jun 2012 07:12:15 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q56BCDru006085 for ; Wed, 6 Jun 2012 05:12:14 -0600 Message-ID: <4FCF3B03.5060603@us.ibm.com> Date: Wed, 06 Jun 2012 19:12:03 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <1338858018-17189-1-git-send-email-mdroth@linux.vnet.ibm.com> <1338858018-17189-2-git-send-email-mdroth@linux.vnet.ibm.com> <4FCDDA12.4040907@redhat.com> <4FCE9B88.2080908@us.ibm.com> <4FCF0AA0.5090105@redhat.com> <4FCF148E.8000104@us.ibm.com> <4FCF16BB.9010804@redhat.com> <4FCF18AC.3080005@us.ibm.com> <4FCF1BD8.4030307@redhat.com> <4FCF201D.7090500@us.ibm.com> <4FCF29E2.2070800@redhat.com> In-Reply-To: <4FCF29E2.2070800@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: yamahata@valinux.co.jp, quintela@redhat.com, Michael Roth , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com, akong@redhat.com, afaerber@suse.de On 06/06/2012 05:58 PM, Avi Kivity wrote: > On 06/06/2012 12:17 PM, Anthony Liguori wrote: >>> >>> So, is it reasonable to say >>> >>> uint32_t * _immutable irrp; // Interrupt Request Register >>> >>> and allocate it on the heap during initialization? >> >> No, this would be wrong. >> >> '_immutable' means that the *state* is immutable from the guests point >> of view. The state stored by: >> >> struct MyDevice { >> Backend _immutable *backend; >> } >> >> Is the *reference* to the backend. The state of the backend is not part >> of the device's state structure. Only the *reference* to the backend is >> part of the device's state and that's immutable. > > I think this has degenerated into a disagreement about naming. Yet I > think this is important. I don't think _immutable suggests "immutable > from the guest's point of view" or even "we assume shared storage [1], > therefore it's immutable" to a device model author or reviewer. I think > we should choose the names under the assumption that the author did not > read the documentation (why bother when you can copy paste another > device model implementation) or read it and immediately forgot it. This > goes double for the reviewer(s). We need to make this as unsubtle as > possible (but no unsubtler). Okay, we're talking past each other then. I'm not really taking a position on the best naming convention to use for these things. This is too early of a patch series. Whether we should have multiple variants of '_immutable' that make it easier for reviewers is something that I'm 100% open too. But I think it's important to have a strong conceptional model. So far, it's built on the following: All device state is serialized unless: a) It's derived from other state b) It's immutable (from the guest PoV) c) We should migrate it but don't know and don't immediately want to change that If we want to subdivide (b) into a set of more specific things, that's perfectly fine by me. But I'm reluctant to just add a "(d) it's host state" because it breaks my mental model. > >> If you think the syntax is confusing, then once you find a time machine, >> I'll happily travel with you 40 years into the past and we can try to >> convince K&R to introduce a richer pointer syntax that allows for >> differentiating between various use-cases of pointers. > > A go port of qemu would be interesting. Perhaps in 10 years. I think go is a little too immature right now. Submit your talks now for KVM Forum 2022 ;-) Regards, Anthony Liguori > > [1] we can also live migrate storage; the real reason it doesn't need > serialization is that it falls under the "by other means" category. >