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 <pbonz...@redhat.com> > >>> > >>> This is a first step towards QOMifying /machine. > >>> > >>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > >> > >> 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. > >
