Re: How to fix CDROM/DVD eject mess?

[Takashi Iwai]

At Mon, 2 Feb 2015 20:03:05 +0100,
Kay Sievers wrote:
> 
> On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> > we've got a bug report about the mishandling of DVD/CDROM media eject
> > button, and it seems indeed broken since some time ago.  In short:
> > when the eject button is pressed, the media is forcibly ejected no
> > matter whether it's mounted or in use.
> 
> Which is the right thing to do for all read-only stuff.

Yes, for read-only, it would be OK if it really does it right.
I raised the question because it doesn't do it so right yet (stale
states and no lock capability).

Also, what if the device is not read-only, e.g. during burning CD/DVD
or mounting DVD-RAM?  Is the immediate forcible eject still the only
option?


> > And, the mount remains even
> > after ejecting the media, eventually the kernel spews error messages
> > when the further access happens.
> 
> This cosmetic issue should be "fixed" if it matters.
> 
> > There seem many problems behind the scene.  First of all, udev tries
> > to lock the media unconditionally at the media insert.  This seems to
> > be a workaround for making DISK_EVENT_EJECT_REQUEST working.
> 
> 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.

The worst point in the current udev rule implementation is that we
lose the tray lock functionality effectively since the udev rule lock
and unlock unconditionally.


> > Then,
> > udev unlocks the media and issues the SCSI eject ioctl unconditionally
> > when DISK_EVENT_EJECT_REQUEST event is received.  Since SCSI ioctl
> > doesn't take the open refcount into account, it results in the
> > forcible eject.
> 
> Which again is the expected behavior in the user's view.

What if user doesn't want?  e.g. DVD/CD media is being burned?


> > (A relevant problem is that CDROM_IOCTL doesn't behave consistently;
> >  it checks the open refcount only for IDE.  For SCSI, it bypasses and
> >  gives the control directly to SCSI backend.  So, using CDROM_EJECT
> >  ioctl won't help as of now.)
> >
> > 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.

Well, it's not quite analogous with USB disconnection, since the
handling of the eject button is a software issue.  From that POV, it's
rather analog to the handling of the power button or the lid switch.

And for such buttons, we do care other things.  The system doesn't
forcibly and directly power off when the button is pressed -- even if
only read-only disk is mounted.

Don't get me wrong: for my own purpose, I don't object to the final
behavior, i.e. the immediate eject of media.  But there are people who
expect differently (the media shouldn't be ejected while in use), or I
would expect that such behavior policy could be managed in the
desktop.  But, no, right now, this is already a fixed policy in the
udev rules, so we can't change it (dynamically or statically) unless
breaking many others.  And an important feature like media lock was
dropped completely.

> We have to handle "the mess" in our tools, meaning cleaning up the stale
> stuff in the kernel or userspace, just like we do with all other
> plugable devices when they ripped out by the user.

The cleanup of the stale state is actually trivial, just replacing
cdrom_id --eject with /usr/bin/eject.  But, I'm not sure whether doing
such a thing is the best solution.

> I'm really not convinced that suppressing events here makes any sense.
> It is just a hardware button event which should not be masked out for
> rather weird reasons.

Heh, I didn't show the patch as a real proposal at all.  Otherwise I'd
have titled as RFC or such.  It's a hack like hell and I hate it too.

That said, if we can manage it in a better way, I'd happily take that
approach.


thanks,

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