qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Mon, 23 Aug 2010 17:00:21 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1

 On 08/23/2010 04:48 PM, Anthony Liguori wrote:
The fundamental issue is: every function (minus trivial ones) in the device models code should have a state reference. That state reference should inherit from a DeviceState. If this statement isn't true, then the device has been modelled in qdev incorrectly.

Using this test, quite a lot of the "converted" devices are being modelled incorrectly.

Is a "state reference" allowed to have a pointer to the state, or reach it in some other way (for example, static storage for singleton devices)?


No. If this was C++, then the statement would be: device have to be implemented in terms of objects that inherit from Device. Device is our common base object.

so,

    struct MyDevicestate {
        struct DeviceState device_state;
        bool *some_bit;
    };

bad, while

    struct MyDevicestate {
        struct DeviceState device_state;
        bool some_bit;
    };

good?


Isn't "save/restore works" an equivalent statement to "device state is reachable from the DeviceState"?

I'm not sure I can connect the dots here as I'm not sure what follows if your assertion is true.

If save/restore works then all state is reachable from one point? Presumable DeviceState?

I really don't see why the state has to be in the DeviceState subclass. We're probably talking past each other here due to some confusion in terms.

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




reply via email to

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