[Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-03 Thread Paolo Bonzini
Since we had to move the state field from DeviceState to Object, we cannot
delay the implementation of the "realized" property.  The property is
a trigger for two actions that propagate through the composition tree.
"Realize" is called when the property becomes true, and propagates in
pre-order; realize can fail if the values of the properties are not valid.
"Unrealize" is called when the property becomes false, and propagates in
post-order; unrealize cannot fail.

Unrealize is also called by object_deinit, as a separate step before
finalization.

Realize/unrealize is separate from reset.  Reset propagation is a thorny
issue of its own.  We expect classes that care to implement a reset method
and call it from realize or realize_children, depending on whether
pre-order or post-order is more appropriate.

This patch adds four methods (realize, realize_children, unrealize,
unrealize_children) to ObjectClass, together with a default implementation
of realize_children and unrealize_children.

Signed-off-by: Paolo Bonzini 
---
 include/qemu/object.h |   20 +++
 qom/object.c  |   93 +
 2 files changed, 113 insertions(+)

diff --git a/include/qemu/object.h b/include/qemu/object.h
index 6db376d..6bded2a 100644
--- a/include/qemu/object.h
+++ b/include/qemu/object.h
@@ -245,6 +245,10 @@ struct ObjectClass
 
 /*< public >*/
 Property *props;
+void (*realize)(Object *obj, struct Error **errp);
+void (*realize_children)(Object *obj, struct Error **errp);
+void (*unrealize)(Object *obj);
+void (*unrealize_children)(Object *obj);
 };
 
 typedef enum ObjectState {
@@ -463,6 +467,22 @@ Object *object_new_with_type(Type type);
 void object_delete(Object *obj);
 
 /**
+ * object_realize_children:
+ * @obj: The object whose children should be realized.
+ *
+ * The default implementation of realize_children.
+ */
+void object_realize_children(Object *obj, struct Error **errp);
+
+/**
+ * object_unrealize_children:
+ * @obj: The object whose children should be unrealize.
+ *
+ * The default implementation of unrealize_children.
+ */
+void object_unrealize_children(Object *obj);
+
+/**
  * object_initialize_with_type:
  * @obj: A pointer to the memory to be used for the object.
  * @type: The type of the object to instantiate.
diff --git a/qom/object.c b/qom/object.c
index 3a6b37b..2a3753a 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -259,6 +259,87 @@ static void object_interface_init(Object *obj, 
InterfaceImpl *iface)
 obj->interfaces = g_slist_prepend(obj->interfaces, iface_obj);
 }
 
+static void object_get_realized(Object *obj, Visitor *v, void *opaque,
+const char *name, Error **errp)
+{
+bool value = object_is_realized(obj);
+
+visit_type_bool(v, &value, name, errp);
+}
+
+static void object_unrealize(Object *obj)
+{
+ObjectClass *klass = object_get_class(obj);
+
+if (klass->unrealize_children) {
+klass->unrealize_children(obj);
+}
+if (obj->state != OBJECT_STATE_CREATED && klass->unrealize) {
+klass->unrealize(obj);
+}
+obj->state = OBJECT_STATE_CREATED;
+}
+
+static int object_unrealize_1(Object *obj, void *unused)
+{
+object_unrealize(obj);
+return 0;
+}
+
+void object_unrealize_children(Object *obj)
+{
+object_child_foreach(obj, object_unrealize_1, NULL);
+}
+
+static void object_realize(Object *obj, Error **errp)
+{
+ObjectClass *klass = object_get_class(obj);
+
+if (obj->state != OBJECT_STATE_REALIZED && klass->realize) {
+klass->realize(obj, errp);
+}
+obj->state = OBJECT_STATE_REALIZED;
+if (klass->realize_children) {
+klass->realize_children(obj, errp);
+}
+}
+
+static int object_realize_1(Object *obj, void *errp)
+{
+Error *err = NULL;
+object_realize(obj, &err);
+if (err) {
+error_propagate((Error **)errp, err);
+return 1;
+}
+
+return 0;
+}
+
+void object_realize_children(Object *obj, Error **errp)
+{
+object_child_foreach(obj, object_realize_1, errp);
+}
+
+static void object_set_realized(Object *obj, Visitor *v, void *opaque,
+const char *name, Error **errp)
+{
+bool value;
+Error *err = NULL;
+
+visit_type_bool(v, &value, name, &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+if (value) {
+object_realize(obj, errp);
+} else {
+object_unrealize(obj);
+}
+}
+
 static void object_init_with_type(Object *obj, TypeImpl *ti)
 {
 int i;
@@ -337,6 +418,8 @@ void object_unparent(Object *obj)
 
 static void object_deinit(Object *obj, TypeImpl *type)
 {
+object_property_set_bool(obj, false, "realized", NULL);
+
 if (type->instance_finalize) {
 type->instance_finalize(obj);
 }
@@ -1239,7 +1322,10 @@ static void object_instance_init(Object *obj)
 Property *prop;
 
 object_property_add_str(obj, "type", qdev_get_type, NUL

Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-03 Thread Andreas Färber
Paolo,

Am 03.04.2012 13:15, schrieb Paolo Bonzini:
> Since we had to move the state field from DeviceState to Object, we cannot
> delay the implementation of the "realized" property.  The property is
> a trigger for two actions that propagate through the composition tree.
> "Realize" is called when the property becomes true, and propagates in
> pre-order; realize can fail if the values of the properties are not valid.
> "Unrealize" is called when the property becomes false, and propagates in
> post-order; unrealize cannot fail.
> 
> Unrealize is also called by object_deinit, as a separate step before
> finalization.
> 
> Realize/unrealize is separate from reset.  Reset propagation is a thorny
> issue of its own.  We expect classes that care to implement a reset method
> and call it from realize or realize_children, depending on whether
> pre-order or post-order is more appropriate.
> 
> This patch adds four methods (realize, realize_children, unrealize,
> unrealize_children) to ObjectClass, together with a default implementation
> of realize_children and unrealize_children.
> 
> Signed-off-by: Paolo Bonzini 

Since this patch is clearly an extended version of my realize patch
http://patchwork.ozlabs.org/patch/148752/, it should carry my SoB, as
reminded last night. If you don't want my SoB on the parts I didn't do -
namely unrealize and *_childen - then feel free to split the patch in
two. Simply dropping attribution in both cover letter and commit just
because I didn't get around yet to sending a v2 with those requests
addressed is not nice!

Patch 24/25 was done differently (calling realized = true from init
rather than the other way around) so this comment only applies to 23/25.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-03 Thread Paolo Bonzini
Il 03/04/2012 14:11, Andreas Färber ha scritto:
> Since this patch is clearly an extended version of my realize patch
> http://patchwork.ozlabs.org/patch/148752/, it should carry my SoB, as
> reminded last night. If you don't want my SoB on the parts I didn't do -
> namely unrealize and *_childen - then feel free to split the patch in
> two. Simply dropping attribution in both cover letter and commit just
> because I didn't get around yet to sending a v2 with those requests
> addressed is not nice!

Technically it's not, because I redid it from scratch (I never even had
time to really look at your patches beyond reading the commit message,
and I did this part while I didn't even have network access).

Paolo



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-05 Thread Paolo Bonzini
Il 05/04/2012 14:04, Andreas Färber ha scritto:
> Am 03.04.2012 15:03, schrieb Paolo Bonzini:
>> Il 03/04/2012 14:11, Andreas Färber ha scritto:
>>> Since this patch is clearly an extended version of my realize patch
>>> http://patchwork.ozlabs.org/patch/148752/, it should carry my SoB, as
>>> reminded last night. If you don't want my SoB on the parts I didn't do -
>>> namely unrealize and *_childen - then feel free to split the patch in
>>> two. Simply dropping attribution in both cover letter and commit just
>>> because I didn't get around yet to sending a v2 with those requests
>>> addressed is not nice!
>>
>> Technically it's not, because I redid it from scratch (I never even had
>> time to really look at your patches beyond reading the commit message,
>> and I did this part while I didn't even have network access).
> 
> That's just as lame an accuse

(Did you mean excuse?)  It's a fact, not an excuse.  Do I need to show
the two patches side-by-side?  That would be even more ridiculous.

But I can very well add a SoB on v2.

> as Fabrice's when he "redid" a patch of rth back in CVS days.

Wasn't there, sorry.

> You were around on IRC on March 23rd when I
> offered to aliguori to put together a patch for realize (which I am
> using in my qom-cpu-sh4 series).

Well, I'm always around, that doesn't mean I always have time to read it.

> I was fair to cc you and Anthony on it, to avoid clashes between those
> of us working on QOM, you commented on my series, so you have read part
> of it; yet you announce the day before your series that you are going to
> send realize and ignore my request to not forget my SoB if you do.
> That makes me think that you're deliberately trying to keep my code 
> contribution out of the picture there, whereas Anthony has stated in
> the context of unicore32 that rewriting someone's contribution to get
> that person's authorship out of the way were not acceptable.

You're assuming I read your patches, which is not the case beyond seeing
that the realize didn't propagate.  There's really nothing deliberate,
and it's quite surprising to me to hear tones escalating so quickly.

Paolo



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-05 Thread Andreas Färber
Am 05.04.2012 14:36, schrieb Paolo Bonzini:
> Il 05/04/2012 14:04, Andreas Färber ha scritto:
>> Am 03.04.2012 15:03, schrieb Paolo Bonzini:
>>> Il 03/04/2012 14:11, Andreas Färber ha scritto:
 Since this patch is clearly an extended version of my realize patch
 http://patchwork.ozlabs.org/patch/148752/, it should carry my SoB, as
 reminded last night. If you don't want my SoB on the parts I didn't do -
 namely unrealize and *_childen - then feel free to split the patch in
 two. Simply dropping attribution in both cover letter and commit just
 because I didn't get around yet to sending a v2 with those requests
 addressed is not nice!
>>>
>>> Technically it's not, because I redid it from scratch (I never even had
>>> time to really look at your patches beyond reading the commit message,
>>> and I did this part while I didn't even have network access).
>>
>> That's just as lame an accuse
> 
> (Did you mean excuse?)

Yes.

>  It's a fact, not an excuse.  Do I need to show
> the two patches side-by-side?  That would be even more ridiculous.

Here's how I see it:

* You add a realize callback to ObjectClass like I did, you add the
Error** parameter that was requested as feedback to mine.
* You add a static object_realize() method that clashes with my
introducing it as a public wrapper function.
* You introduce a function object_get_realized() like I did, only you
defer your implementation to object_is_realized() which I didn't have
and used a new bool realized instead of a state enum (since I left qdev
unmodified).
* You introduce a function object_set_realized() like I did, only you
change the logic to also do unrealize.
* You introduce additional stuff that I don't particularly care about.

So my point is, whether you've read some patch or not, I just can't
understand why you couldn't wait a week for me to resend the updated
version and rush it so much that you ignore existing patches that were
actually coordinated with Anthony
(https://github.com/afaerber/qemu-cpu/commit/bc78ab1c0e4ba375bc5942447644323281184a31
on qom-cpu-sh4 branch already incorporates pm215's wish of a dedicated
QERR, f.ex.).

While having unrealize and propagation is certainly nice, the most
serious issue with yours I see is that it doesn't offer me a way to
actually make use of it outside qdev, so that *I* am left with no
benefit from your patch!

Some practical thoughts on how to align both approaches would be helpful
here. For starters, should I name my function object_realize_nofail()
instead? And could you prefer _one over _1 in your patch please?

If your problem is Signed-off-by specifically, feel free to invent some
inofficial tag such as Inspired-by or Derived-from-commit-message-by or
resort to a textual reference.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-05 Thread Paolo Bonzini
Il 05/04/2012 15:31, Andreas Färber ha scritto:
> Here's how I see it:
> 
> * You add a realize callback to ObjectClass like I did, you add the
> Error** parameter that was requested as feedback to mine.
> * You add a static object_realize() method that clashes with my
> introducing it as a public wrapper function.
> * You introduce a function object_get_realized() like I did, only you
> defer your implementation to object_is_realized() which I didn't have
> and used a new bool realized instead of a state enum (since I left qdev
> unmodified).
> * You introduce a function object_set_realized() like I did, only you
> change the logic to also do unrealize.
> * You introduce additional stuff that I don't particularly care about.

Since we're nitpicking, I also do correct error propagation.

> So my point is, whether you've read some patch or not, I just can't
> understand why you couldn't wait a week for me to resend the updated
> version

Because a week is a long time 10 days before the feature freeze, and
(via object_is_realized and a few other small bits) the whole series
depends on the implementation of realized.

> While having unrealize and propagation is certainly nice, the most
> serious issue with yours I see is that it doesn't offer me a way to
> actually make use of it outside qdev, so that *I* am left with no
> benefit from your patch!

Can you explain?  I definitely would need to fix this.

> Some practical thoughts on how to align both approaches would be helpful
> here. For starters, should I name my function object_realize_nofail()
> instead?

Yes, that would be an idea.  I would hope that long-term there would be
only one object_realize call during in initial machine creation (i.e.
except for hot-plug), but it would be fine as a start.

> And could you prefer _one over _1 in your patch please?

Yes.

> If your problem is Signed-off-by specifically, feel free to invent some
> inofficial tag such as Inspired-by or Derived-from-commit-message-by or
> resort to a textual reference.

I can add the SoB, no problem.

Paolo



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-05 Thread Anthony Liguori
Hi,

I'm about to board a plane but I at least want to comment that we should
all give each other the benefit of the doubt in a situation like this.
Everyone on this thread is a long term contributer to QEMU that has more
than earned the right not to be accussed of impropriety.  Let's all take a
deep breathe and tone down this discussion in this thread by assuming that
noone is intentionally doing anything wrong
On Apr 5, 2012 9:17 AM, "Paolo Bonzini"  wrote:

> Il 05/04/2012 15:31, Andreas Färber ha scritto:
> > Here's how I see it:
> >
> > * You add a realize callback to ObjectClass like I did, you add the
> > Error** parameter that was requested as feedback to mine.
> > * You add a static object_realize() method that clashes with my
> > introducing it as a public wrapper function.
> > * You introduce a function object_get_realized() like I did, only you
> > defer your implementation to object_is_realized() which I didn't have
> > and used a new bool realized instead of a state enum (since I left qdev
> > unmodified).
> > * You introduce a function object_set_realized() like I did, only you
> > change the logic to also do unrealize.
> > * You introduce additional stuff that I don't particularly care about.
>
> Since we're nitpicking, I also do correct error propagation.
>
> > So my point is, whether you've read some patch or not, I just can't
> > understand why you couldn't wait a week for me to resend the updated
> > version
>
> Because a week is a long time 10 days before the feature freeze, and
> (via object_is_realized and a few other small bits) the whole series
> depends on the implementation of realized.
>
> > While having unrealize and propagation is certainly nice, the most
> > serious issue with yours I see is that it doesn't offer me a way to
> > actually make use of it outside qdev, so that *I* am left with no
> > benefit from your patch!
>
> Can you explain?  I definitely would need to fix this.
>
> > Some practical thoughts on how to align both approaches would be helpful
> > here. For starters, should I name my function object_realize_nofail()
> > instead?
>
> Yes, that would be an idea.  I would hope that long-term there would be
> only one object_realize call during in initial machine creation (i.e.
> except for hot-plug), but it would be fine as a start.
>
> > And could you prefer _one over _1 in your patch please?
>
> Yes.
>
> > If your problem is Signed-off-by specifically, feel free to invent some
> > inofficial tag such as Inspired-by or Derived-from-commit-message-by or
> > resort to a textual reference.
>
> I can add the SoB, no problem.
>
> Paolo
>


Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-04-05 Thread Andreas Färber
Am 03.04.2012 15:03, schrieb Paolo Bonzini:
> Il 03/04/2012 14:11, Andreas Färber ha scritto:
>> Since this patch is clearly an extended version of my realize patch
>> http://patchwork.ozlabs.org/patch/148752/, it should carry my SoB, as
>> reminded last night. If you don't want my SoB on the parts I didn't do -
>> namely unrealize and *_childen - then feel free to split the patch in
>> two. Simply dropping attribution in both cover letter and commit just
>> because I didn't get around yet to sending a v2 with those requests
>> addressed is not nice!
> 
> Technically it's not, because I redid it from scratch (I never even had
> time to really look at your patches beyond reading the commit message,
> and I did this part while I didn't even have network access).

That's just as lame an accuse as Fabrice's when he "redid" a patch of
rth back in CVS days. You were around on IRC on March 23rd when I
offered to aliguori to put together a patch for realize (which I am
using in my qom-cpu-sh4 series). Had you volunteered back then, I
wouldn't have invested time and we wouldn't be having this discussion.
But if there's something I hate more than political extremism, it's
having my time wasted.

I was fair to cc you and Anthony on it, to avoid clashes between those
of us working on QOM, you commented on my series, so you have read part
of it; yet you announce the day before your series that you are going to
send realize and ignore my request to not forget my SoB if you do. That
makes me think that you're deliberately trying to keep my code
contribution out of the picture there, whereas Anthony has stated in the
context of unicore32 that rewriting someone's contribution to get that
person's authorship out of the way were not acceptable.

Apart from the personal disrespect this implies here, it's also about me
wanting to prove my bosses that I don't just sit in an arm chair or
write useless crap. My patch is available under GPLv2+ allowing anyone
to freely modify and reuse that code but doing so without copyright and
authorship attribution is in violation of the license. I respect
people's contributions and am all in favor of documenting people's
effort with Reported-by, Tested-by, Reviewed-by, and I expect that
others respect mine too.

You had me write a trivial follow-up to your series, which I did now, so
you should consider living to the same standard and following up on mine.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-05-09 Thread Igor Mammedov
Hi Paolo,

Are you plannig to respin this and related patches?
If yes, when?

On Tue, Apr 03, 2012 at 01:15:51PM +0200, Paolo Bonzini wrote:
> Since we had to move the state field from DeviceState to Object, we cannot
> delay the implementation of the "realized" property.  The property is
> a trigger for two actions that propagate through the composition tree.
> "Realize" is called when the property becomes true, and propagates in
> pre-order; realize can fail if the values of the properties are not valid.
> "Unrealize" is called when the property becomes false, and propagates in
> post-order; unrealize cannot fail.
> 
> Unrealize is also called by object_deinit, as a separate step before
> finalization.
> 
> Realize/unrealize is separate from reset.  Reset propagation is a thorny
> issue of its own.  We expect classes that care to implement a reset method
> and call it from realize or realize_children, depending on whether
> pre-order or post-order is more appropriate.
> 
> This patch adds four methods (realize, realize_children, unrealize,
> unrealize_children) to ObjectClass, together with a default implementation
> of realize_children and unrealize_children.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  include/qemu/object.h |   20 +++
>  qom/object.c  |   93 
> +
>  2 files changed, 113 insertions(+)
> 
> diff --git a/include/qemu/object.h b/include/qemu/object.h
> index 6db376d..6bded2a 100644
> --- a/include/qemu/object.h
> +++ b/include/qemu/object.h
> @@ -245,6 +245,10 @@ struct ObjectClass
>  
>  /*< public >*/
>  Property *props;
> +void (*realize)(Object *obj, struct Error **errp);
> +void (*realize_children)(Object *obj, struct Error **errp);
> +void (*unrealize)(Object *obj);
> +void (*unrealize_children)(Object *obj);
>  };
>  
>  typedef enum ObjectState {
> @@ -463,6 +467,22 @@ Object *object_new_with_type(Type type);
>  void object_delete(Object *obj);
>  
>  /**
> + * object_realize_children:
> + * @obj: The object whose children should be realized.
> + *
> + * The default implementation of realize_children.
> + */
> +void object_realize_children(Object *obj, struct Error **errp);
> +
> +/**
> + * object_unrealize_children:
> + * @obj: The object whose children should be unrealize.
> + *
> + * The default implementation of unrealize_children.
> + */
> +void object_unrealize_children(Object *obj);
> +
> +/**
>   * object_initialize_with_type:
>   * @obj: A pointer to the memory to be used for the object.
>   * @type: The type of the object to instantiate.
> diff --git a/qom/object.c b/qom/object.c
> index 3a6b37b..2a3753a 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -259,6 +259,87 @@ static void object_interface_init(Object *obj, 
> InterfaceImpl *iface)
>  obj->interfaces = g_slist_prepend(obj->interfaces, iface_obj);
>  }
>  
> +static void object_get_realized(Object *obj, Visitor *v, void *opaque,
> +const char *name, Error **errp)
> +{
> +bool value = object_is_realized(obj);
> +
> +visit_type_bool(v, &value, name, errp);
> +}
> +
> +static void object_unrealize(Object *obj)
> +{
> +ObjectClass *klass = object_get_class(obj);
> +
> +if (klass->unrealize_children) {
> +klass->unrealize_children(obj);
> +}
> +if (obj->state != OBJECT_STATE_CREATED && klass->unrealize) {
> +klass->unrealize(obj);
> +}
> +obj->state = OBJECT_STATE_CREATED;
> +}
> +
> +static int object_unrealize_1(Object *obj, void *unused)
> +{
> +object_unrealize(obj);
> +return 0;
> +}
> +
> +void object_unrealize_children(Object *obj)
> +{
> +object_child_foreach(obj, object_unrealize_1, NULL);
> +}
> +
> +static void object_realize(Object *obj, Error **errp)
> +{
> +ObjectClass *klass = object_get_class(obj);
> +
> +if (obj->state != OBJECT_STATE_REALIZED && klass->realize) {
> +klass->realize(obj, errp);
> +}
> +obj->state = OBJECT_STATE_REALIZED;
> +if (klass->realize_children) {
> +klass->realize_children(obj, errp);
> +}
> +}
> +
> +static int object_realize_1(Object *obj, void *errp)
> +{
> +Error *err = NULL;
> +object_realize(obj, &err);
> +if (err) {
> +error_propagate((Error **)errp, err);
> +return 1;
> +}
> +
> +return 0;
> +}
> +
> +void object_realize_children(Object *obj, Error **errp)
> +{
> +object_child_foreach(obj, object_realize_1, errp);
> +}
> +
> +static void object_set_realized(Object *obj, Visitor *v, void *opaque,
> +const char *name, Error **errp)
> +{
> +bool value;
> +Error *err = NULL;
> +
> +visit_type_bool(v, &value, name, &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
> +if (value) {
> +object_realize(obj, errp);
> +} else {
> +object_unrealize(obj);
> +}
> +}
> +
>  static void object_init_with_type(

Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-05-10 Thread Paolo Bonzini
Il 09/05/2012 22:01, Igor Mammedov ha scritto:
> Hi Paolo,
> 
> Are you plannig to respin this and related patches?
> If yes, when?

After the first part goes in (21 patches including Anthony's bus
series).  A reviewed-by from Andreas or Anthony would help, so that I
can make Andreas's suggested documentation changes and send a pull
request to someone.

Andreas, would you object to being honorary maintainer of qom-next for
this month?

Paolo



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-05-10 Thread Andreas Färber
Am 10.05.2012 09:05, schrieb Paolo Bonzini:
> Il 09/05/2012 22:01, Igor Mammedov ha scritto:
>> Hi Paolo,
>>
>> Are you plannig to respin this and related patches?
>> If yes, when?
> 
> After the first part goes in (21 patches including Anthony's bus
> series).  A reviewed-by from Andreas or Anthony would help, so that I
> can make Andreas's suggested documentation changes and send a pull
> request to someone.
> 
> Andreas, would you object to being honorary maintainer of qom-next for
> this month?

Sometimes there's so many trees that one doesn't see the forrest... I
brought that topic up in
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00926.html:

> there's more and more colliding patch series on the list -
> fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
> need a strategy to coordinate our ongoing development and post-1.1
> merging. Someone needs to rebase on someone else, question is whom.

If Anthony is okay with me maintaining a qom-next branch then I'd
happily do that! It doesn't relieve us of reviewing and acking each
other's patches though. And in particular we need to figure out how to
proceed with your and Anthony's series - I have stated opinions on some
parts, but it's Anthony's baby.

Also, I still think there's at least one patch in your series that
should go into 1.1 (the -device fix thingy).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 23/25] qom: add realized property

2012-05-10 Thread Anthony Liguori

On 05/10/2012 05:01 AM, Andreas Färber wrote:

Am 10.05.2012 09:05, schrieb Paolo Bonzini:

Il 09/05/2012 22:01, Igor Mammedov ha scritto:

Hi Paolo,

Are you plannig to respin this and related patches?
If yes, when?


After the first part goes in (21 patches including Anthony's bus
series).  A reviewed-by from Andreas or Anthony would help, so that I
can make Andreas's suggested documentation changes and send a pull
request to someone.

Andreas, would you object to being honorary maintainer of qom-next for
this month?


Sometimes there's so many trees that one doesn't see the forrest... I
brought that topic up in
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00926.html:


there's more and more colliding patch series on the list -
fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
need a strategy to coordinate our ongoing development and post-1.1
merging. Someone needs to rebase on someone else, question is whom.


If Anthony is okay with me maintaining a qom-next branch then I'd
happily do that! It doesn't relieve us of reviewing and acking each
other's patches though. And in particular we need to figure out how to
proceed with your and Anthony's series - I have stated opinions on some
parts, but it's Anthony's baby.


Yeah, I'd be more than happy with you maintaining a qom-next tree.

Regards,

Anthony Liguori



Also, I still think there's at least one patch in your series that
should go into 1.1 (the -device fix thingy).

Andreas