Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965013AbbBCNuG (ORCPT ); Tue, 3 Feb 2015 08:50:06 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34195 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751944AbbBCNuB (ORCPT ); Tue, 3 Feb 2015 08:50:01 -0500 Date: Tue, 03 Feb 2015 14:49:59 +0100 Message-ID: From: Takashi Iwai To: One Thousand Gnomes Cc: Kay Sievers , Jens Axboe , Oliver Neukum , LKML Subject: Re: How to fix CDROM/DVD eject mess? In-Reply-To: <20150203133906.1a2c14f6@lxorguk.ukuu.org.uk> References: <20150203133906.1a2c14f6@lxorguk.ukuu.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") 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: 1573 Lines: 36 At Tue, 3 Feb 2015 13:39:06 +0000, One Thousand Gnomes wrote: > > > > It is no workaround, it's the SCSI spec. You only see events if you > > > lock the door. > > > > Yeah, I do understand the reason behind it. But: why udev has to take > > care of SCSI implementation details at this place at all? Isn't the > > place for the generic cdrom device? If it's only for obtaining the > > eject events, you're essentially working around the problem. Instead, > > the kernel should have provided a saner way to enable the event > > generation, IMO. > > You could take that to the SCSI and ATA committee's and then try and get > them to agree and every vendor on the planet to make every crapware USB > device implement it. Good luck. > > The kernel can provide only the lowest common denominator of service if > it provides a single unified model. In CD space thats a *very low common > denominator* I meant the saner way ioctl implementation, not about something about the new hardware control. Currently, the media lock ioctl is used as a way to enable the event. So we can't handle the additional media lock properly since the state is a bool in kernel. If it's a flag with two bits (one for the media lock and one for the event enablement), user-space doesn't need to track the state by itself, for example. Takashi -- 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/