[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/3] block: detach devices from DriveInfo at unr
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 1/3] block: detach devices from DriveInfo at unrealize time |
Date: |
Wed, 23 Mar 2016 10:35:57 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 23/03/2016 09:35, Markus Armbruster wrote:
>> by that time you don't have anymore a QOM path to include in the event.
>
> I see. To delay DEVICE_DELETED, we'd have to save the QOM path, and
> that would be bothersome.
Not just that, the QOM path goes away at the time we currently raise
DEVICE_DELETED. If we delay it to finalization, it might even have been
reused.
> Still, copying code from property to devices with that property is
> undesirable. It's not that bad in this patch, because we copy only to
> the devices that do warty backend deletion, and that's just the two
> places where we call blockdev_mark_auto_del() now. However, it gets
> worse if we decide to extend warty backend deletion to *all* devices:
> more places, and a new need to consistently copy it to every new user of
> the drive property.
>
> When you find yourself copying code from a property callback into every
> device using it, the real problem might be you're missing a callback.
> In this case, one that runs at unrealize time. The existing release()
> runs at finalize time.
That's certainly a good thing to do if we decide to extend autodeletion
to the NVMe and SD devices.
Paolo