From: Takashi Iwai <tiwai@suse.de>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Kay Sievers <kay@vrfy.org>, 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?
Date: Tue, 03 Feb 2015 14:49:59 +0100 [thread overview]
Message-ID: <s5hy4ofcdfc.wl-tiwai@suse.de> (raw)
In-Reply-To: <20150203133906.1a2c14f6@lxorguk.ukuu.org.uk>
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
next prev parent reply other threads:[~2015-02-03 13:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 13:20 How to fix CDROM/DVD eject mess? Takashi Iwai
2015-02-02 19:03 ` Kay Sievers
2015-02-02 19:34 ` Maciej W. Rozycki
2015-02-02 19:45 ` Kay Sievers
2015-02-02 21:12 ` Maciej W. Rozycki
2015-02-03 12:36 ` Takashi Iwai
2015-02-03 8:52 ` Oliver Neukum
2015-02-03 13:34 ` One Thousand Gnomes
2015-02-03 17:53 ` Theodore Ts'o
2015-02-02 20:02 ` Austin S Hemmelgarn
2015-02-02 20:53 ` Ondrej Zary
2015-02-03 12:31 ` Takashi Iwai
2015-02-03 13:39 ` One Thousand Gnomes
2015-02-03 13:49 ` Takashi Iwai [this message]
2015-02-03 13:40 ` Austin S Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hy4ofcdfc.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=axboe@kernel.dk \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oneukum@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.