Il 09/12/2013 17:48, Igor Mammedov ha scritto: >> > >> > We could have separate check/plug methods. Only check can fail, it must >> > be idempotent, and it can be invoked while the device is still unrealized. > Reasons I've stated before apply to 'check' as well, for only specific device > knows > when it's fine to call it. That would just replace "plug" with "check" in > realize() > for not much of benefit.
Check is idempotent, and can be called before realize makes any change (it could also be called after the device is added to /machine/unattached, it's not a big difference). Plug is called after realize. >> > >> > The reason I liked the interface, is because it removes the need for >> > each bus to add its own plug/unplug handling. > ^^^ > Have you meant device instead of bus? I meant each bus-specific abstract class (PCIDevice, SCSIDevice, etc.). > It's still improvement over current PCI hotplug code and allows to simplify > other buses as well by removing callbacks from them. Exactly. But so far you don't get any benefit: no removal of PCI hotplug code, no removal of allow_hotunplug. What I'm proposing, I believe, has a small cost and already starts the transition (which I believe we can complete for 2.0). > The only way to call callbacks from DEVICE.realize()/unplug(), I see, is if > we make > them all nofail, then it would be safe to call them in "realize" property > setter. > But we have at least 2 callbacks that can fail: > pcie_cap_slot_hotplug() and shpc_device_hotplug() Both of them can be handled by a "check" step in the handler. > Goal of this series was to add and demonstrate reusable hotplug interface as > opposed to PCI specific or SCSI-bus specific ones, so it could be used for > memory > hotplug as well. It might not do everything we would like but it looks like a > move > the right direction. > If it's wrong direction, I could drop the idea and fallback to an original > less intrusive approach, taking in account your comment to move type > definitions > into separate header. No, absolutely. I think it's the right direction, I just think more aspects of it should be made generic. Paolo
