[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Date: Wed, 06 Jun 2012 19:12:03 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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 

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]