Message-ID: <54CFD7CF.9080809@gmail.com>
Date: Mon, 02 Feb 2015 15:02:23 -0500
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@linux-mips.org>, Kay Sievers <kay@vrfy.org>
CC: Takashi Iwai <tiwai@suse.de>, Jens Axboe <axboe@kernel.dk>,
        Oliver Neukum <oneukum@suse.de>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: How to fix CDROM/DVD eject mess?
References: <s5hmw4wfo1b.wl-tiwai@suse.de> <CAPXgP10BwNkXqMPGbRkjgt3R9rMv6sZ9EX1nP9X99cAfmcaOXw@mail.gmail.com> <alpine.LFD.2.11.1502021915110.22715@eddie.linux-mips.org>
In-Reply-To: <alpine.LFD.2.11.1502021915110.22715@eddie.linux-mips.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909040106050100000406"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 6928
Lines: 136

This is a cryptographically signed message in MIME format.

--------------ms020909040106050100000406
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 2015-02-02 14:34, Maciej W. Rozycki wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>>> I thought that fixing the udev behavior would solve the problem.  But=

>>> it turned out that I was too naive.  A bigger problem is that all
>>> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
>>> see this as if the disk is *ready* to be ejected.  KDE, for example,
>>> dismisses the DVD icon when it receives this event even if it's still=

>>> mounted.
>>
>> It is not really about being "ready to eject", if the user presses the=

>> button, the user does not want to wait for anything else than actually=

>> ejecting the media as fast as possible. It is the same as ripping out
>> a USB cable. It needs to work, no matter if things are mounted or
>> busy.
>
>   All the technical details aside, this is a bold statement -- how do y=
ou
> know what the user actually wants?
>
>   I for one want to see the medium locked if in use, just as it has bee=
n
> since 1990s.  If I wanted to do an emergency eject (the equivalent of
> ripping out a USB cable), then I would use a paperclip in the manual ej=
ect
> hole.  So you've got a counterexample to your assertion now.  All peopl=
e
> are not the same.
>
>   All I want to say here is there seems to be a policy hidden somewhere=

> here where it should not.  It's up to the user to decide what suits him=
 or
> her.  We just need to give them the right tools.
>
>> It is just a hardware button event which should not be masked out for
>> rather weird reasons.
>
>   Precisely, and I should have a way to control it.  If I used a GUI, I=

> might want the event to pop up a window with the list of current users
> (accessing processes) of the device, perhaps asking if to terminate the=
m.
> Or flip a relay to make my kettle boil water.

I agree, there should be some option to control this, although=20
personally, I would prefer two options, one for when it's read-only (in=20
which case I would prefer the current behavior), and one for when it's=20
read-write (in which case, I would prefer that the door-lock be engaged).=


Also, udev's current response isn't all that great either, when it get's =

the event, it should do a lazy unmount of the device.  Windows and OS X=20
automatically unmount filesystems from ejected media, so it is expected=20
behavior for many users (and I keep meaning to open a bug against udev=20
because of this, but keep forgetting).

The fact that it stays mounted can cause all kinds of confusing issues=20
as well if the user inserts a different disc; I've seen cases (recently=20
in fact) where a new disc was inserted and due to caching, it showed=20
dentries from the old disc, but with the files full of gibberish, and it =

refused to unmount the (now invalid) filesystem without using umount -f=20
(which shouldn't be needed for a read-only FS, period).


--------------ms020909040106050100000406
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuDCC
BbQwggOcoAMCAQICAw9gVDANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDA4
MDgxMTMwNDRaFw0xNTAyMDQxMTMwNDRaMGMxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEj
MCEGCSqGSIb3DQEJARYUYWhmZXJyb2luN0BnbWFpbC5jb20xIjAgBgkqhkiG9w0BCQEWE2Fo
ZW1tZWxnQG9oaW9ndC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDdmm8R
BM5D6fGiB6rpogPZbLYu6CkU6834rcJepfmxKnLarYUYM593/VGygfaaHAyuc8qLaRA3u1M0
Qp29flqmhv1VDTBZ+zFu6JgHjTDniBii1KOZRo0qV3jC5NvaS8KUM67+eQBjm29LhBWVi3+e
a8jLxmogFXV0NGej+GHIr5zA9qKz2WJOEoGh0EfqZ2MQTmozcGI43/oqIYhRj8fRMkWXLUAF
WsLzPQMpK19hD8fqwlxQWhBV8gsGRG54K5pyaQsjne7m89SF5M8JkNJPH39tHEvfv2Vhf7EM
Y4WGyhLAULSlym1AI1uUHR1FfJaj3AChaEJZli/AdajYsqc7AgMBAAGjggFZMIIBVTAMBgNV
HRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUg
Zm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E
BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEE
AYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8v
b2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9y
Zy9yZXZva2UuY3JsMDQGA1UdEQQtMCuBFGFoZmVycm9pbjdAZ21haWwuY29tgRNhaGVtbWVs
Z0BvaGlvZ3QuY29tMA0GCSqGSIb3DQEBDQUAA4ICAQCr4klxcZU/PDRBpUtlb+d6JXl2dfto
OUP/6g19dpx6Ekt2pV1eujpIj5whh5KlCSPUgtHZI7BcksLSczQbxNDvRu6LNKqGJGvcp99k
cWL1Z6BsgtvxWKkOmy1vB+2aPfDiQQiMCCLAqXwHiNDZhSkwmGsJ7KHMWgF/dRVDnsl6aOQZ
jAcBMpUZxzA/bv4nY2PylVdqJWp9N7x86TF9sda1zRZiyUwy83eFTDNzefYPtc4MLppcaD4g
Wt8U6T2ffQfCWVzDirhg4WmDH3MybDItjkSB2/+pgGOS4lgtEBMHzAGQqQ+5PojTHRyqu9Jc
O59oIGrTaOtKV9nDeDtzNaQZgygJItJi9GoAl68AmIHxpS1rZUNV6X8ydFrEweFdRTVWhUEL
70Cnx84YBojXv01LYBSZaq18K8cERPLaIrUD2go+2ffjdE9ejvYDhNBllY+ufvRizIjQA1uC
OdktVAN6auQob94kOOsWpoMSrzHHvOvVW/kbokmKzaLtcs9+nJoL+vPi2AyzbaoQASVZYOGW
pE3daA0F5FJfcPZKCwd5wdnmT3dU1IRUxa5vMmgjP20lkfP8tCPtvZv2mmI2Nw5SaXNY4gVu
WQrvkV2in+TnGqgEIwUrLVbx9G6PSYZZs07czhO+Q1iVuKdAwjL/AYK0Us9v50acIzbl5CWw
ZGj3wjGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMPYFQwCQYFKw4DAhoFAKCCAfUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMjAyMjAwMjIz
WjAjBgkqhkiG9w0BCQQxFgQUrsPOJMNcUPChOdoA21qtV0MxL6kwbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAE
MYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0
Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ
ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMPYFQwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAO
BgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE
AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBj
YWNlcnQub3JnAgMPYFQwDQYJKoZIhvcNAQEBBQAEggEARhZUZZquyR8JsUShrAY16wuB7hny
wTSr90u92YR9lme5vNHQeBeNGNaC4Qv4tRU3vAOZ0dtDBVJQoonZoc9bFjyoOkBi8W5QufXG
rJjlFAztc/rumjeGm53vRNojPRC1jFbLDpbDEMVAZmHkyQUgit1VOiNUOISgbVebyG4g7LAV
YW1c89BoFYvQ+CbFOE1r6my7PkQXAi14E/AuAOdrrb2yArS823CeML8uWRhFNcGOOjNS1SuX
7AeHoyOk2UMKCU4pQ79fLjAjhU1pM5D5shboPvqJlDkIqcNMeQgCmwkFQVzuXPvSGCvjajie
HL4gVhsulO5vEUTQvqh0E2G5nwAAAAAAAA==
--------------ms020909040106050100000406--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/