On 01/03/2012 02:18 AM, Anthony Liguori wrote:
2) Why do you need a list for the interface objects at all? You can make
obj->interfaces point to a single blob, and initialize the objects in
place. You
only need to store the number of interfaces into the TypeImpl or in
the object
header, or add a
On 01/02/2012 11:59 AM, Paolo Bonzini wrote:
On 12/20/2011 05:51 PM, Anthony Liguori wrote:
hw/object.c | 469 +
hw/object.h | 427 +++
A couple more remarks:
1) Please put it outside hw/
D
On 01/02/2012 05:01 PM, Andreas Färber wrote:
Am 22.12.2011 20:57, schrieb Anthony Liguori:
On 12/22/2011 12:00 PM, Kevin O'Connor wrote:
On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
Why not declare types with something like th
Am 22.12.2011 20:57, schrieb Anthony Liguori:
> On 12/22/2011 12:00 PM, Kevin O'Connor wrote:
>> On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
>>> On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
Why not declare types with something like the following:
TypeInfo my_dev
On 12/20/2011 05:51 PM, Anthony Liguori wrote:
hw/object.c | 469 +
hw/object.h | 427 +++
A couple more remarks:
1) Please put it outside hw/
2) Why do you need a list for the inte
On 12/22/2011 06:25 PM, Kevin O'Connor wrote:
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = "my-device",
.parentinfo =&device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, looku
On 12/22/2011 12:00 PM, Kevin O'Connor wrote:
On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
I used a symbolic type name to avoid the problem of dependencies.
In ord
On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
> On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
> >On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
> >>I used a symbolic type name to avoid the problem of dependencies.
> >>In order to create a type in gobject, you ha
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
On 12/21/2011 07:35 AM, Paolo Bonzini wrote:
What's the need for "Type"? You can use simply the TypeImpl * and drop
type_get_instance. Outside object.h it can be an opaque pointer.
I
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
> On 12/21/2011 07:35 AM, Paolo Bonzini wrote:
> >What's the need for "Type"? You can use simply the TypeImpl * and drop
> >type_get_instance. Outside object.h it can be an opaque pointer.
>
> It's a bit nicer for type_register to re
On 12/21/2011 03:35 PM, Anthony Liguori wrote:
+Type type_register_static(const TypeInfo *info)
+{
+ Type type = num_types++;
+ TypeImpl *ti;
+
+ ti =&type_table[type];
+
+ assert(info->name != NULL);
+
+ printf("Added type %s -> %s\n", info->name, info->parent);
+
+ ti->name = info->name;
Why
On 12/21/2011 07:35 AM, Paolo Bonzini wrote:
On 12/20/2011 05:51 PM, Anthony Liguori wrote:
This class provides the main building block for QEMU Object Model and is
extensively documented in the header file. It is largely inspired by GObject.
Signed-off-by: Anthony Liguori
---
Makefile.objs | 2
On 12/20/2011 05:51 PM, Anthony Liguori wrote:
This class provides the main building block for QEMU Object Model and is
extensively documented in the header file. It is largely inspired by GObject.
Signed-off-by: Anthony Liguori
---
Makefile.objs |2 +
hw/object.c | 469 ++
This class provides the main building block for QEMU Object Model and is
extensively documented in the header file. It is largely inspired by GObject.
Signed-off-by: Anthony Liguori
---
Makefile.objs |2 +
hw/object.c | 469 +
hw/ob
14 matches
Mail list logo
