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

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

On 06/05/2012 06:06 PM, Avi Kivity wrote:
> On 06/05/2012 04:00 AM, Michael Roth wrote:
> In addition, QC can decide at run time whether to
>> +suppress a field by assigning it a **default** value.
>> +
>> +## Immutable Fields
>> +
>> +If a field is only set during device construction, based on parameters passed to
>> +the device's constructor, then there is no need to send save and restore this
>> +value.  We call these fields immutable and we tell QC about this fact by using
>> +a **_immutable** marker.
>> +
>> +In our *SerialDevice* example, the *CharDriverState* pointer reflects the host
>> +backend that we use to send serial output to the user.  This is only assigned
>> +during device construction and never changes.  This means we can add an
>> +**_immutable** marker to it:
>
> Even if it does change (suppose we add a monitor command to retarget a
> the serial device's chardev), it need not be migrated since it doesn't
> describe guest state, only host state.  Maybe we should mark *chr _host
> instead of _immutable.

No, this is just another example of C's type system sucking and being ambiguous.

Consider the following example:

struct PS2Keyboard {
     DeviceState parent;

     PCKBDState _immutable *controller; // link
     ...
};

This is definitely '_immutable' even though *something* has to marshal that 
PCKBDState.  That's because this is a reference to an externally managed object. 
  As long as references don't change due to guest initiated actions, they're 
immutable.

In the case of a CharDriverState, the reference is always immutable.  If we 
supported changing char backends dynamically, it would not happen by changing 
the reference, but almost certainly by having the ability to reopen the char 
driver in place.  IOW, while the referenced object changes, the reference 
doesn't change.

Contrast that to:

struct PS2Keyboard {
     DeviceState parent;

     QEMUTimer *timer;
     ...
};

This could be just as well written as:

struct PS2Keyboard {
     DeviceState parent;

     QEMUTimer timer;
     ...
};

It's just a detail of our implementation that we allocate the timer on the heap. 
  So while it's still a pointer, it's not really a reference to an external 
object.  It's an embedded object and therefore must be considered for serialization.

Regards,

Anthony Liguori