|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup |
Date: | Mon, 23 Aug 2010 08:48:51 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 08/23/2010 08:42 AM, Avi Kivity wrote:
GPIO is just one way for a device to talk, same as (*bus)_phys_memory_rw() or its netdev or its chardev or its timers. It doesn't need to have special status within DeviceState, but it doesn't hurt so much that I can tell.Everything extra hurts when you're trying to move code in to a library with unit tests covering the functionality :-)Sure, it's a worthy cleanup. But it's not a reason to go to DEFCON 1.
I think you're reading too much into my late night rantings ;-)
But being able to associate timers with devices seems like a very good idea to me because it means that you can see which devices are registering timers.You might also have the timers auto-cancelled and auto-destroyed on device removal. But the whole thing seems like a minor coding issue rather than something fundamental.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.
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.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |