|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor |
Date: | Wed, 06 Jun 2012 17:17:17 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |