Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755085AbbBBTel (ORCPT ); Mon, 2 Feb 2015 14:34:41 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:38904 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754992AbbBBTek (ORCPT ); Mon, 2 Feb 2015 14:34:40 -0500 Date: Mon, 2 Feb 2015 19:34:38 +0000 (GMT) From: "Maciej W. Rozycki" To: Kay Sievers cc: Takashi Iwai , Jens Axboe , Oliver Neukum , LKML Subject: Re: How to fix CDROM/DVD eject mess? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1961 Lines: 44 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? 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. 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 them. Or flip a relay to make my kettle boil water. FWIW, Maciej -- 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/