[systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
oneukum at suse.de
Mon Jan 12 05:02:50 PST 2015
On Mon, 2015-01-12 at 04:46 -0800, Greg KH wrote:
> > 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.
Well, we have been polling in kernel space since 3.13
> > 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.
No, for currently udev doesn't care. And the choice is pretty
clear anyway. We are not going to refuse to use the device, are we?
So we'll use it anyway. The question is, do we lock if we can?
> > 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?
Yes and and that is not the problem.
> > 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
I am afraid I am forced to strongly disagree with your statement.
The kernel does have a default policy. It locks the door upon
open() (which is implied in mount())
If you press the button during such a lock, an event is passed
to user space.
The question is why udev contains a rule that overrides the kernel
and in user space implements an effective policy of no door locking.
> 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?
Could you elaborate on how to use udisks if udev has a rule that
unconditionally ejects media if the button is pressed? And what
is wrong with the kernel's default?
More information about the systemd-devel