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

[Paolo Bonzini <pbonzini@redhat.com>]

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

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).

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.
> If we go with such an interim solution then at least qdev.c needs to
> grow an assert.