From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScCMy-0003Ii-FM for qemu-devel@nongnu.org; Wed, 06 Jun 2012 05:17:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScCMs-00073H-5y for qemu-devel@nongnu.org; Wed, 06 Jun 2012 05:17:36 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:59354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScCMs-000732-1w for qemu-devel@nongnu.org; Wed, 06 Jun 2012 05:17:30 -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 05:17:26 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id C1A9638C8026 for ; Wed, 6 Jun 2012 05:17:23 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q569HNPl26083408 for ; Wed, 6 Jun 2012 05:17:23 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q569HMb2011363 for ; Wed, 6 Jun 2012 06:17:23 -0300 Message-ID: <4FCF201D.7090500@us.ibm.com> Date: Wed, 06 Jun 2012 17:17:17 +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> In-Reply-To: <4FCF1BD8.4030307@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 04:59 PM, Avi Kivity wrote: > On 06/06/2012 11:45 AM, Anthony Liguori wrote: >>> Ok. But then the backend pointer is not 'const Backend * const', it's >>> 'Backend * const' (if we don't allow retargeting). So we can't say it's >>> _immutable (and it isn't). It's _host. >> >> 'Backend * const' is immutable >> >> That is, the *pointer* is immutable. What it points to is not. > > 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. Contrast this to: struct MyDevice { uint32_t *irrp; } Where iirp is stored on the heap. While the state is on the heap, it is effectively owned by the MyDevice structure. irrp is not a reference to another object but just an indirect address of an extension of the device state. 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. >> If you want to '#define _host _immutable' as a way to improve >> readability, I'm not against that. But from a conceptional perspective, >> we don't migrate it because nothing the guest does changes it. It's >> immutable from the guests PoV. > > It's not only immutable from the guest point of view, it's unreadable as > well. That's what _host means -- it doesn't exist as far as the guest > is concerned. IMO that's different than immutable. This isn't true. Block device backends are absolutely readable within the guest. But for live migration, they don't change because we assume shared storage. Therefore it's immutable :-) Regards, Anthony Liguori >