Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine

[Paolo Bonzini]

Il 28/02/2014 16:57, Andreas Färber ha scritto:
> Am 28.02.2014 16:08, schrieb Alexey Kardashevskiy:
> > On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
> > > Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
> > > > On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
> > > > > On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
> > > > > > Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
> > > > > > > > > Each of them highlights one of the two aspects that, in my opinion,
> > > > > > > > > make
> > > > > > > > > QOM interesting (respectively, unification of interfaces and the
> > > > > > > > > containment tree).
> > > > > > > I was planning to tackle the replacement of the machine from a container
> > > > > > > to an actual object too, however this patch conflicts with my
> > > > > > > series because I already have a QOM Machine object created *always*
> > > > > > > and this patch adds another object *sometimes*.
> > > > > > >
> > > > > > > Is this patch's functionality in use yet? Any idea how to merge those
> > > > > > > ideas?
> > > > > >
> > > > > > pseries simply wants to make /machine implement the FWPathProvider
> > > > > > interface.  As long as you have a way for boards to specify a TypeInfo
> > > > > > for /machine, this patch will not get in the way.
> > > > > Thanks Paolo! I'll be aware not to brake this functionality.
> > > > > Marcel
> > > >
> > > > What is the outcome of this discussion for the patches I posted? Do I have
> > > > to wait till you finish that machine properties rework and repost or...?
> > >
> > > Your patches are fine.
>
> I disputed that in this case and asked for a code change in qdev code
> either not creating the container and/or asserting that that code path
> is not hit.

You're right.  The outcome of the discussion was not that the patches 
are fine, but rather that they need not be blocked by Marcel's work.  I 
was too terse/vague/wrong---sorry.

> > >  Who gets in first, wins.  The other, rebases. :)
>
> Negative, qemu.git is not a tombola. If there's known issues they need
> to be fixed before merging. But yes, when there's two "good" approaches
> then it's a matter of merge order, which ideally should involve
> communication rather than competition among maintainers. Because the
> pull that does not apply then gets bounced by Peter.

Right, hence the smiley.  People that submit patches should be aware of 
conflicting series and tell the maintainers about it.

Paolo