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

[Anthony Liguori]

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)

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

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.

> > 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 ;-)

Regards,

Anthony Liguori

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