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
