[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 07:51:36 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/05/2012 06:06 PM, Avi Kivity wrote:
On 06/05/2012 04:00 AM, Michael Roth wrote:
In addition, QC can decide at run time whether to
+suppress a field by assigning it a **default** value.
+## Immutable Fields
+If a field is only set during device construction, based on parameters passed 
+the device's constructor, then there is no need to send save and restore this
+value.  We call these fields immutable and we tell QC about this fact by using
+a **_immutable** marker.
+In our *SerialDevice* example, the *CharDriverState* pointer reflects the host
+backend that we use to send serial output to the user.  This is only assigned
+during device construction and never changes.  This means we can add an
+**_immutable** marker to it:

Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), it need not be migrated since it doesn't
describe guest state, only host state.  Maybe we should mark *chr _host
instead of _immutable.

No, this is just another example of C's type system sucking and being ambiguous.

Consider the following example:

struct PS2Keyboard {
    DeviceState parent;

    PCKBDState _immutable *controller; // link

This is definitely '_immutable' even though *something* has to marshal that PCKBDState. That's because this is a reference to an externally managed object. As long as references don't change due to guest initiated actions, they're immutable.

In the case of a CharDriverState, the reference is always immutable. If we supported changing char backends dynamically, it would not happen by changing the reference, but almost certainly by having the ability to reopen the char driver in place. IOW, while the referenced object changes, the reference doesn't change.

Contrast that to:

struct PS2Keyboard {
    DeviceState parent;

    QEMUTimer *timer;

This could be just as well written as:

struct PS2Keyboard {
    DeviceState parent;

    QEMUTimer timer;

It's just a detail of our implementation that we allocate the timer on the heap. So while it's still a pointer, it's not really a reference to an external object. It's an embedded object and therefore must be considered for serialization.


Anthony Liguori

reply via email to

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