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

[Marcel Apfelbaum]

On Thu, 2014-02-27 at 11:41 +0100, Paolo Bonzini wrote:
> Il 27/02/2014 11:34, Andreas Färber ha scritto:
> > Am 20.02.2014 14:58, schrieb Paolo Bonzini:
> >> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto:
> >>> From: Paolo Bonzini <address@hidden>
> >>>
> >>> This is a first step towards QOMifying /machine.
> >>>
> >>> Signed-off-by: Paolo Bonzini <address@hidden>
> >>
> >> The patch was originally mine, so I could get it in if Andreas wants me
> >> to handle patches 2-3.  But for anyone else it would be missing your
> >> S-o-b line.
> >
> > With this patch I have been plagued by doubts of whether we can run into
> > a race of creating /machine through qdev_get_machine() via command line
> > option handling or whatever other code paths.
I'd like to understand this issue, can anybody elaborate a little on the 
possible race?

>  I'm at a conference and
> > did not find time yet to test this out - if you two could investigate
> > and clarify, that would be helpful in moving forward.
> >
> > Also I thought that someone else had looked into replacing the whole of
> > machine_init and QEMUMachine with QOM infrastructure?
> 
> Yes, that was Marcel.
Yes, I am working on that and planning to send an RFC V2 really soon.
> 
> I think that Alexey's patch and Marcel's approach are just two different 
> parts of the same project.
> 
> Marcel's is more general and focused on option handling, and the main 
> idea is to convert -machine suboptions to properties.  Alexey's is 
> instead focused on using the QOM tree and the "contained-in" 
> relationship as a basis for providing machine-specific (and possibly 
> SoC-specific) hooks.
> 
> 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?

> Paolo
> 
> > Anyway it was an
> > idea that I once had, Anthony didn't like at first and then someone else
> > (Luiz?) convinced Anthony to do it after all but then somehow it got
> > stuck with no patches posted... The discussed approach was instead of
> > creating a type in machine init depending on some
> > QEMUMachine::class_name, always create the type. But either approach
> > conflicts with creating /machine as Container type, as mentioned above.
As I am going with the *always* approach and hoping to replace /machine
with a QOM object, what is the conflict here?

Thanks,
Marcel

> > If we go with such an interim solution then at least qdev.c needs to
> > grow an assert.
> 
>