Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor

[Anthony Liguori <aliguori@us.ibm.com>]

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

>