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

[Avi Kivity <avi@redhat.com>]

On 06/06/2012 12:17 PM, Anthony Liguori wrote:
>>
>> 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.

I think this has degenerated into a disagreement about naming.  Yet I
think this is important.  I don't think _immutable suggests "immutable
from the guest's point of view" or even "we assume shared storage [1],
therefore it's immutable" to a device model author or reviewer.  I think
we should choose the names under the assumption that the author did not
read the documentation (why bother when you can copy paste another
device model implementation) or read it and immediately forgot it.  This
goes double for the reviewer(s).  We need to make this as unsubtle as
possible (but no unsubtler).

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

A go port of qemu would be interesting.

[1] we can also live migrate storage; the real reason it doesn't need
serialization is that it falls under the "by other means" category.

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