qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 1/2] qdev-monitor.c: Register reset function


From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v1 1/2] qdev-monitor.c: Register reset function if the device has one
Date: Thu, 18 Feb 2016 10:47:19 -0800

On Thu, Feb 18, 2016 at 1:56 AM, Markus Armbruster <address@hidden> wrote:
> Alistair Francis <address@hidden> writes:
>
>> If the device being added when running qdev_device_add() has
>> a reset function, register it so that it can be called.
>>
>> Signed-off-by: Alistair Francis <address@hidden>
>> ---
>>
>>  qdev-monitor.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>> index 81e3ff3..0a99d01 100644
>> --- a/qdev-monitor.c
>> +++ b/qdev-monitor.c
>> @@ -561,6 +561,8 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
>> **errp)
>>
>>      if (bus) {
>>          qdev_set_parent_bus(dev, bus);
>> +    } else if (dc->reset) {
>> +        qemu_register_reset((void (*)(void *))dc->reset, dev);
>>      }
>>
>>      id = qemu_opts_id(opts);
>
> This looks wrong to me.
>
> You stuff all the device reset methods into the global reset_handlers
> list, where they get called in some semi-random order.  This breaks when
> there are reset order dependencies between devices, e.g. between a
> device and the bus it plugs into.

So I'm not a expert on this, but from what I see this will also be
added near the end of the list (before the rom_resets though) and
doesn't seem to be a problem. Do you have any other ideas how the
reset function could be registered?

Thanks,

Alistair

>
> Propagating the reset signal to all the devices is a qdev problem.
> Copying Andreas for further insight.
>



reply via email to

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