Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Tue, 20 Mar 2007, Shem Multinymous wrote: More like it is a make sure we can actually eject, as we have been told to. We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 eject). Which stage are you referring to? Stage 2, of course. It is useful to have a force_eject functionality that **will** eject and not error out because of anything other than the eject command itself failing. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On 3/19/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: True. The best available procedure to do this for ACPI bay/dock currently is, AFAIK: 1. Send event when bay/dock please release button/lever is pressed. Do *nothing* else. I know bay does this right, maybe dock doesn't. 2. Wait for something to echo 1 eject or to call the appropriate routine directly, or (if this exists) for an notification from firmware that the user IS disconnecting the device for real. 3. delete the device. This means force-umount, force-close, etc. 4. Tell the hardware to eject. Note that currently (2) and (3) are swapped, as (3) is being done by userspace request, instead of by the kernel. This is something I *don't* like. Userspace wants to (non-force-)-unmount by itself after (1), so it can stop the eject process if the filesystems cannot be cleanly unmounted. So the force-unmount at (3) ends up being a redundant safety measure at best. Shem - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Mon, 19 Mar 2007, Shem Multinymous wrote: Userspace wants to (non-force-)-unmount by itself after (1), so it can stop the eject process if the filesystems cannot be cleanly unmounted. So the force-unmount at (3) ends up being a redundant safety measure at best. More like it is a make sure we can actually eject, as we have been told to. We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 eject). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
