Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani <hidden>
Date: 2013-02-04 19:56:36
Also in:
linux-acpi, linux-mm, linux-s390, lkml
On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote:
On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote:quoted
On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote:quoted
On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote:quoted
On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote:quoted
On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote::quoted
quoted
quoted
Yes, but those are just remove events and we can only see how destructive they were after the removal. The point is to be able to figure out whether or not we *want* to do the removal in the first place.Yes, but, you will always race if you try to test to see if you can shut down a device and then trying to do it. So walking the bus ahead of time isn't a good idea. And, we really don't have a viable way to recover if disconnect() fails, do we. What do we do in that situation, restore the other devices we disconnected successfully? How do we remember/know what they were? PCI hotplug almost had this same problem until the designers finally realized that they just had to accept the fact that removing a PCI device could either happen by: - a user yanking out the device, at which time the OS better clean up properly no matter what happens - the user asked nicely to remove a device, and the OS can take as long as it wants to complete that action, including stalling for noticable amounts of time before eventually, always letting the action succeed. I think the second thing is what you have to do here. If a user tells the OS it wants to remove these devices, you better do it. If you can't, because memory is being used by someone else, either move them off, or just hope that nothing bad happens, before the user gets frustrated and yanks out the CPU/memory module themselves physically :)Well, that we can't help, but sometimes users really *want* the OS to tell them if it is safe to unplug something at this particualr time (think about the Windows' "safe remove" feature for USB sticks, for example; that came out of users' demand AFAIR). So in my opinion it would be good to give them an option to do "safe eject" or "forcible eject", whichever they prefer.For system device hot-plug, it always needs to be "safe eject". This feature will be implemented on mission critical servers, which are managed by professional IT folks. Crashing a server causes serious money to the business.Well, "always" is a bit too strong a word as far as human behavior is concerned in my opinion. That said I would be perfectly fine with not supporting the "forcible eject" to start with and waiting for the first request to add support for it. I also would be fine with taking bets on how much time it's going to take for such a request to appear. :-)
Sounds good. In my experience, though, it actually takes a LONG time to convince customers that "safe eject" is actually safe. Enterprise customers are so afraid of doing anything risky that might cause the system to crash or hang due to some defect. I would be very surprised to see a customer asking for a force operation when we do not guarantee its outcome. I have not seen such enterprise customers yet. Thanks, -Toshi