[systemd-devel] cdrom_id and 60-cdrom_id.rules behavior

[Martin Pitt]

Andrei Borzenkov [2015-01-15 11:24 +0300]:
> So what's the point of locking tray in the first place if it will be
> unlocked as soon as you press eject button?

So that we can do a clean unmount and avoid the situation in the
original post :-) Also, we can delay or fail the unlocking and
ejection if the device is busy, e. g.  during burning. With the eject
button directly working without telling userspace, we could never lock
it during writing, nor do a clean unmounting.

> > Right, because we didn't have the kernel (or userspace in udisks, as
> > it was before that) polling for eject button presses. But users (IMHO
> > rightfully) complained about the non-working button, and with the
> > current system it's indeed so much more natural (if it works :) ).
> >
> 
> You call it natural that now we apparently do not have any way to
> actually lock CD tray?

Well, you deny someone with physical access the usage of a physical
button. For any read-only mount I don't consider that friendly.
Locking is of course desirable (and ought to work) if the device is
being written to.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)