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

[Avi Kivity <avi@redhat.com>]

On 06/06/2012 02:12 PM, Anthony Liguori wrote:
> On 06/06/2012 05:58 PM, Avi Kivity wrote:
>> 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).
> 
> Okay, we're talking past each other then.
> 
> I'm not really taking a position on the best naming convention to use
> for these things.  This is too early of a patch series.  Whether we
> should have multiple variants of '_immutable' that make it easier for
> reviewers is something that I'm 100% open too.
> 
> But I think it's important to have a strong conceptional model.  So far,
> it's built on the following:
> 
> All device state is serialized unless:
> 
>  a) It's derived from other state
> 
>  b) It's immutable (from the guest PoV)

I'm harping again on naming, but using _immutable to mean
_immutable_from_the_guest_point_of_view is confusing.  _immutable means
_immutable.  I don't think people will be able to answer "is this
immutable from a guest point of view" easily.

> 
>  c) We should migrate it but don't know and don't immediately want to
> change that

d) the RAM migration code takes care of migrating it

e) the block layer takes care of migrating it

> If we want to subdivide (b) into a set of more specific things, that's
> perfectly fine by me.  But I'm reluctant to just add a "(d) it's host
> state" because it breaks my mental model.

Suppose you save/restore a guest that is connected to a host cdrom.  The
cdrom tray state (and indeed the cdrom data) should not be
save/restored, because you want the real (host) data to be used after
restore.  The same is true for a serial device that is connected to a
host serial device and reads line state from it.

> 
>>
>>> 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.
> 
> Perhaps in 10 years.  I think go is a little too immature right now. 
> Submit your talks now for KVM Forum 2022 ;-)

In 10 years go would be old and crusty and I'd be drumming for the hot
new language of the day.

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