linux-kernel - Re: How to fix CDROM/DVD eject mess?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2015 20:45:50 +0100
From:	Kay Sievers <kay@...y.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Takashi Iwai <tiwai@...e.de>, Jens Axboe <axboe@...nel.dk>,
	Oliver Neukum <oneukum@...e.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: How to fix CDROM/DVD eject mess?

On Mon, Feb 2, 2015 at 8:34 PM, Maciej W. Rozycki <macro@...ux-mips.org> 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 you
> know what the user actually wants?

By working with people who spent a lot of time with the questions what
the default behavior of user interfaces should be. Buttons, especially
physical ones, need to give immediate feedback to the user. If they
don't give it it, people will look for something else to get what they
want.

>  I for one want to see the medium locked if in use, just as it has been
> 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 eject
> hole.  So you've got a counterexample to your assertion now.  All people
> are not the same.

It's just the current default setup and intentional behavior. You or
your distribution can for sure implement something else.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/