qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
	"Liu >> \"Liu, Jinsong\"" <jinsong.liu@intel.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Mon, 23 Aug 2010 09:26:38 -0500	[thread overview]
Message-ID: <4C72851E.50405@codemonkey.ws> (raw)
In-Reply-To: <4C727EF5.6060402@redhat.com>

On 08/23/2010 09:00 AM, Avi Kivity wrote:
>  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?

And the next logical question is whether:

struct MyDeviceState {
    DeviceState qdev;
    OtherState *s;
};

Is bad?  The answer would depend on whether OtherState implemented 
methods or not.  If OtherState has no methods, it's fine.  If it has 
methods, it's bad.

>
>
>>
>>> 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.

Probably.  Let's say that 'structs' are containers of primatives that 
have no methods associated with them.  'objects' are structs that have 
methods and potentially constructors/destructors.

Devices can contain references to structs and objects.  If a Device 
contains a reference to an object, the object should be stored in a 
BusState which is a container of Devices.  Therefore, the object should 
inherit from Device.

Regards,

Anthony Liguori

  reply	other threads:[~2010-08-23 14:26 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-12 21:14 [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup Blue Swirl
2010-06-13 16:56 ` [Qemu-devel] " Jan Kiszka
2010-06-13 17:03   ` Andreas Färber
2010-06-13 17:53     ` Blue Swirl
2010-06-13 18:17       ` Andreas Färber
2010-06-13 17:49   ` Blue Swirl
2010-08-19 19:33 ` [Qemu-devel] " Anthony Liguori
2010-08-19 20:09   ` Blue Swirl
2010-08-19 20:49     ` Anthony Liguori
2010-08-19 21:21       ` Blue Swirl
2010-08-19 21:51         ` Anthony Liguori
2010-08-19 22:52           ` malc
2010-08-20  1:01             ` Anthony Liguori
2010-08-20 10:00               ` malc
2010-08-20  8:42           ` [Qemu-devel] " Paolo Bonzini
2010-08-20 17:01           ` [Qemu-devel] " Markus Armbruster
2010-08-20 18:38             ` Anthony Liguori
2010-08-22 20:28               ` Avi Kivity
2010-08-22 21:02                 ` Anthony Liguori
2010-08-23  5:46                   ` Avi Kivity
2010-08-23 13:23                     ` Anthony Liguori
2010-08-23 13:42                       ` Avi Kivity
2010-08-23 13:48                         ` Anthony Liguori
2010-08-23 14:00                           ` Avi Kivity
2010-08-23 14:26                             ` Anthony Liguori [this message]
2010-08-23 14:32                               ` Avi Kivity
2010-08-23 14:47                                 ` Anthony Liguori
2010-08-23 15:10                                   ` Markus Armbruster
2010-08-23 16:05                                     ` Anthony Liguori
2010-08-23 17:36                                       ` Markus Armbruster
2010-08-23 17:47                                         ` Anthony Liguori
2010-08-23 18:24                                       ` [Qemu-devel] " Jan Kiszka
2010-08-23 18:29                                         ` Anthony Liguori
2010-08-23 15:14                                   ` [Qemu-devel] " Avi Kivity
2010-08-23 16:02                                     ` Anthony Liguori
2010-08-24  9:51                                       ` Avi Kivity
2010-08-20 19:26           ` Blue Swirl
2010-08-20 10:35       ` [Qemu-devel] " Jan Kiszka
2010-08-22  9:37       ` [Qemu-devel] " Avi Kivity
2010-08-22 18:52         ` Anthony Liguori
2010-08-22 19:44           ` Avi Kivity
2010-08-22 20:03             ` Anthony Liguori
2010-08-22 20:33               ` Avi Kivity
2010-08-22 21:06                 ` Anthony Liguori
2010-08-23  5:49                   ` Avi Kivity
2010-08-23  9:09                     ` [Qemu-devel] " Jan Kiszka
2010-08-23  9:25                       ` Avi Kivity
2010-08-23 10:11                         ` Alexander Graf
2010-08-23 10:15                           ` Avi Kivity
2010-08-23 10:18                             ` Alexander Graf
2010-08-23 10:25                               ` Avi Kivity
2010-08-22 21:07             ` [Qemu-devel] " Anthony Liguori
2010-08-23  5:48               ` Avi Kivity
2010-08-22  9:13   ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C72851E.50405@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=jinsong.liu@intel.com \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).