From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEMZ-0003Bj-ML for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:25:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScEMU-0000q5-Lo for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEMU-0000pr-E4 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:25:14 -0400 Message-ID: <4FCF3E10.90506@redhat.com> Date: Wed, 06 Jun 2012 14:25:04 +0300 From: Avi Kivity 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> <4FCF3B03.5060603@us.ibm.com> In-Reply-To: <4FCF3B03.5060603@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori 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 02:12 PM, Anthony Liguori wrote: > 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) I'm harping again on naming, but using _immutable to mean _immutable_from_the_guest_point_of_view is confusing. _immutable means _immutable. I don't think people will be able to answer "is this immutable from a guest point of view" easily. > > c) We should migrate it but don't know and don't immediately want to > change that d) the RAM migration code takes care of migrating it e) the block layer takes care of migrating it > 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. Suppose you save/restore a guest that is connected to a host cdrom. The cdrom tray state (and indeed the cdrom data) should not be save/restored, because you want the real (host) data to be used after restore. The same is true for a serial device that is connected to a host serial device and reads line state from it. > >> >>> 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 ;-) In 10 years go would be old and crusty and I'd be drumming for the hot new language of the day. -- error compiling committee.c: too many arguments to function