> > > > I like the idea of disconnect; if part of the device_del method was to > > > > invoke a disconnect method, we could implement that for block, net, etc; > > > > > > > > I'd think we'd want to send the notification, then disconnect. > > > > Struggling with whether it's worth having some reasonable timeout > > > > between notification and disconnect. > > > > > > The problem with this is that it has no analog in real world. > > > In real world, you can send some notifications to the guest, and you can > > > remove the card. Tying them together is what created the problem in the > > > first place. > > > > > > Timeouts can be implemented by management, maybe with a nice dialog > > > being shown to the user. > > > > Very true. I'm fine with forcing a disconnect during the removal path > > prior to notification. Do we want a new disconnect method at the device > > level (pci)? or just use the existing removal callback and call that > > during the initial hotremov event? > > Not sure what you mean by that, but I don't see a device doing anything > differently wrt surprise or ordered removal. So probably the existing > callback should do. I don't think we need to talk about disconnect: > since we decided we are emulating device removal, let's call it > just that.
Because current the "removal" process depends on the guest actually responding. What I'm suggesting is that, in Marcus's term, and what drive_unplug() implements, is to disconnect the host block device from the guest device to prevent any further access to it in the case the guest doesn't respond to the removal request made via ACPI. Very specifically, what we're suggesting instead of the drive_unplug() command so to complete the device removal operation without waiting for the guest to respond; that's what's going to happen if we invoke the response callback; it will appear as if the guest responded whether it did or not. What I was suggesting above was to instead of calling the callback for handing the guest response was to add a device function called disconnect which would remove any association of host resources from guest resources before we notified the guest. Thinking about it again I'm not sure this is useful, but if we're going to remove the device without the guests knowledge, I'm not sure how useful sending the removal requests via ACPI is in the first place. My feeling is that I'd like to have explicit control over the disconnect from host resources separate from the device removal *if* we're going to retain the guest notification. If we don't care to notify the guest, then we can just do device removal without notifying the guest and be done with it. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
