On Monday, February 04, 2013 04:04:47 PM Greg KH wrote: > On Tue, Feb 05, 2013 at 12:52:30AM +0100, Rafael J. Wysocki wrote: > > You'd probably never try to hot-remove a disk before unmounting filesystems > > mounted from it or failing it as a RAID component and nobody sane wants the > > kernel to do things like that automatically when the user presses the eject > > button. In my opinion we should treat memory eject, or CPU package eject, or > > PCI host bridge eject in exactly the same way: Don't eject if it is not > > prepared for ejecting in the first place. > > Bad example, we have disks hot-removed all the time without any > filesystems being unmounted, and have supported this since the 2.2 days > (although we didn't get it "right" until 2.6.) I actually don't think it is really bad, because it exposes the problem nicely. Namely, there are two arguments that can be made here. The first one is the usability argument: Users should always be allowed to do what they want, because it is [explicit content] annoying if software pretends to know better what to do than the user (it is a convenience argument too, because usually it's *easier* to allow users to do what they want). The second one is the data integrity argument: Operations that may lead to data loss should never be carried out, because it is [explicit content] disappointing to lose valuable stuff by a stupid mistake if software allows that mistake to be made (that also may be costly in terms of real money). You seem to believe that we should always follow the usability argument, while Toshi seems to be thinking that (at least in the case of the "system" devices), the data integrity argument is more important. They are both valid arguments, however, and they are in conflict, so this is a matter of balance. You're saying that in the case of disks we always follow the usability argument entirely. I'm fine with that, although I suspect that some people may not be considering this as the right balance. Toshi seems to be thinking that for the hotplug of memory/CPUs/host bridges we should always follow the data integrity argument entirely, because the users of that feature value their data so much that they pretty much don't care about usability. That very well may be the case, so I'm fine with that too, although I'm sure there are people who'll argue that this is not the right balance either. Now, the point is that we *can* do what Toshi is arguing for and that doesn't seem to be overly complicated, so my question is: Why don't we do that, at least to start with? If it turns out eventually that the users care about usability too, after all, we can add a switch to adjust things more to their liking. Still, we can very well do that later. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
