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

[Greg KH]

On Mon, Jan 12, 2015 at 01:33:46PM +0100, Oliver Neukum wrote:
> On Mon, 2015-01-12 at 04:15 -0800, Greg KH wrote:
> > On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote:
> > > Hello, a while back, around 2011, in cdrom_id was added --eject-media,
> > > --lock-media and --unlock-media for not much explanation.
> > > 
> > > Now, recently some people noticed that this might actually be a
> > > problem. 
> > > 
> > > Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418
> > > 
> > > Here is a scenario:
> > > 
> > > 1. add a CD/DVD into the driver
> > > 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't
> > > use the Gnome/KDE auto-mounting or reproduce this in a server setup)
> > > 3. eject the media (using the hardware button) and add a new one media
> > > (different disk)
> > > 4. ls /mnt/my_cd (it will be an empty output or the previous media)
> > > 
> > > Is this expected?
> > 
> > Yes, because you didn't unmount the media and tell the kernel that the
> > filesystem is now gone.
> 
> You are correct, but not really helpful :)

Sorry, it's early in the morning for me :)

> Let me rephrase. Is this desirable?

Probably not.  But with some hardware, as you have seen, you need to run
some type of userspace daemon to poll the device to handle media removal
issues when the hardware itself does not report media removal.

> It doesn't tell us whether the hardware button should eject the medium
> in the first place.

Some hardware doesn't allow you to lock the door, so this question comes
down to what to do if you try to lock it but it does not happen.

> > > Also, I remember a while back (long time ago) that
> > > once you added a media into the driver and it was properly mounted, you
> > > couldn't eject the media until you unmounted the media.
> > 
> > It depends on the hardware, some devices support this, others don't.
> 
> If the device does not support locking the door, the question is moot.

Agreed.

> We need to be able to handle surprise removal. That doesn't mean we
> should in effect never lock the door if we can do so.

I think we support locking the door, if userspace asks to, right?

> > > NOTE: This works somewhat OK in the desktop setup, probably due to
> > > udisks (using Gnome/KDE), but in the console not really.
> > 
> > Then use udisks :)
> 
> To do what? The kernel on its own and udev on their own behave
> differently. What is the correct way?

The kernel on its own does not dictate this type of policy, it's up to
userspace to determine if you want to lock the door when you mount
something, and to poll the device to detect media removal if the device
is broken and does not report such things.

That is why systems use udisks today, to handle all of these issues.
Why not just use it?

thanks,

greg k-h