[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: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor |
Date: |
Wed, 06 Jun 2012 14:25:04 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
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
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, (continued)
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/05
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Peter Maydell, 2012/06/05
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Avi Kivity, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Avi Kivity, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Avi Kivity, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Avi Kivity, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor,
Avi Kivity <=
- Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor, Anthony Liguori, 2012/06/06
[Qemu-devel] [PATCH 06/17] qapi: qapi-visit.py, add gen support for existing types, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 05/17] qapi: qapi-visit.py, support arrays and complex qapi definitions, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 07/17] qapi: add open-coded visitors for QEMUTimer/struct tm types, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 08/17] rtc: move RTCState declaration to header, Michael Roth, 2012/06/04
[Qemu-devel] [PATCH 09/17] rtc: add qc annotations, Michael Roth, 2012/06/04