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: 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). Which stage are you referring to? Note that the only way to check if you can unmount is to actually do so. Otherwise, you're very likely to run into race conditions with someone accessing the filesystem between the check and the actual unmount. 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
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
