From: Takashi Iwai <tiwai@suse.de>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
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 13:36:49 +0100 [thread overview]
Message-ID: <s5h61bjdvdq.wl-tiwai@suse.de> (raw)
In-Reply-To: <alpine.LFD.2.11.1502022050170.22715@eddie.linux-mips.org>
At Mon, 2 Feb 2015 21:12:34 +0000 (GMT),
Maciej W. Rozycki wrote:
>
> > > 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.
>
> Fair enough, but if this is a matter of decisions made by a distribution,
> then why is this an issue raised on LKML? What does it have to do with
> the kernel or why does it have to be addressed in the kernel, one way or
> another? Or does it indeed?
I originally raised the question to LKML since there are open problems
in the kernel side, too. For example, the eject event can be
generated only when the media is locked. It's a specification of
SCSI, but it doesn't mean that we have to provide only this way.
And, another issue is that DISK_EJECT_REQUESTED event is treated by
all user-space programs as if the device is actually ejected. It's a
misuse in user-space side, so ideally it's no kernel issue. But if
all user-space stuff misuses, it becomes it's right -- no matter what
is the original definition by kernel, I'm afraid.
Also, as already mentioned, the cdrom device ioctl behavior is
inconsistent among SCSI and others.
Takashi
next prev parent reply other threads:[~2015-02-03 12:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 13:20 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 [this message]
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
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=s5h61bjdvdq.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=axboe@kernel.dk \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®