qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine
Date: Thu, 27 Feb 2014 11:41:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]