On Mo 05. Mai - 23:33:57, Matthew Garrett wrote: > 48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as > detached if an acpi eject request is received. In 2.6.24 and earlier, an > eject request merely sent an event to userland which could then cleanly > unmount the device and let the user know when it was safe to remove the > drive. Removing the device would then send another acpi request that > triggered the actual hotplug and bus rescan. What second acpi request are you referring to? > This seems like a regression - it's no longer possible to ensure that a > bay device is cleanly unmounted. Was this really the desired behaviour? I'm thinking about his for several days now and looking for a proper solution how to ensure that userland has the possibility to cleanly unmount a device. But it's definitely no regression. Before...systems with a bay in a dock stations simply froze hard in certain circumstances. It was pure luck that it worked for one major kernel version or so. The only sane way for me seems that userland has to be involved before actually triggering any event or removing any device. Something like "savely remove this piece of hardware". For this to archive, we would need another sysfs entry flagging a bay device as "on dock station", so that userland knows what to unmount/eject before a dock event. Userspace relying on the bay event on the device is not a proper solution. The device may have been gone before userland finishes his work, or as you mention, there's no bay event. > It should be noted that not all hardware sends the eject request at all > (Thinkpads do, but Dell and HP laptops don't), so we can't depend on > receiving this when dealing with a bay event. I don't think we depend on the event. If the device gets removed without an appropriate event, the behaviour should be the same as before. If not, that wasn't the intentional behaviour. Regards, Holger -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
