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

[Avi Kivity]

On 06/06/2012 02:51 AM, Anthony Liguori wrote:
>>> +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 fact C allows you to express this:

  const T *foo;   // *foo may not change, but foo may
  T * const foo;  // foo may not change, but *foo may

Although every time I see this, I have to stop and think, which activity
I usually try to avoid.  So your example would be written

  PCKBDState * _immutable controller; // link

if we adopt the same system.  But I wasn't referring to that at all.
Instead, some state is simply not relevant to the guest view, even
though it is state.  We don't have a lot of that since most host state
is behind nice interfaces, but think of a vga device that keeps track of
the host window size and alt-ctrl status.  Those are not guest state and
need not be migrated.

> 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.

In either case, state changes.  The reason we don't send it over is
because it's not guest state, not because we reopen in place or not (and
migration shouldn't depend on how we choose to implement changing
chardev backends -- reopen or delete/new).


-- 
error compiling committee.c: too many arguments to function