qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 6/7] vl: Set current_machine early


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 6/7] vl: Set current_machine early
Date: Tue, 20 Aug 2013 11:09:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Andreas Färber <address@hidden> writes:

> Am 19.08.2013 11:35, schrieb Markus Armbruster:
>> Andreas Färber <address@hidden> writes:
>> 
>>> Am 16.08.2013 15:18, schrieb address@hidden:
>>>> From: Markus Armbruster <address@hidden>
>>>>
>>>> I'd like to access QEMUMachine from a QEMUMachine init() method, which
>>>> is currently not possible.  Instead of passing it as an argument, I
>>>> simply set current_machine earlier.
>>>
>>> We had such a patch for CPU hot-add and decided against doing this.
>>> Currently current_machine != signals that it has been initialized. And
>> 
>> Does any code actually depend on this undocumented condition?  I found
>> none.
>
> I didn't audit. Currently the users are limited to vl.c itself,
> device-hotplug.c for block_default_type and qmp.c for hot_add_cpu. pc.c
> feels odd in that mix.
>
> [...]
>>> Can't you pass either QEMUMachine or the specific fields needed from PC
>>> code to those SMBIOS functions? You did add a bool argument.
>> 
>> Can't see how to do that without passing the machine to QEMUMachine
>> method init(), which involves touching all boards.  I doubt that's a
>> good idea, but if you insist, I can do it.
>
> Isn't that exactly what QEMUMachineArgs was meant to address? :)
> Had a look at your don't-explode patches and they looked good.

I could give it a try, but to be honest, I'm reluctant to base new work
on a series that has been ignored by all committers for more than two
months.



reply via email to

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