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




Reply via email to