Re: [REGRESSION] cdrom drive doesn't detect removal

[Kay Sievers]

On Thu, Sep 23, 2010 at 10:47, Tejun Heo <tj@xxxxxxxxxx> wrote:

> Yeah, what I'm curious about is why hal behaves differently with
> claiming block patch. ÂExclusive open still fails with EBUSY with or
> without the patch, right? ÂSo, why does hal behave differently?

We don't support unlocked cd doors. Currently eject/umount of optical
media has to be initiated by the user.

HAL checked if the device was mounted, and if it was, it dropped the
O_EXCL. This was to support polling of the eject-button state, which
worked on a few drives. That's no longer cecked with udisks, it does
O_EXCL only for optical media.

>> Look if it fails. sure the device is open, but if doesn't fail, nothing
>> prevents a bit less honest clients (that don't use exclusive open) to
>> open the device. How exclusive such an open is then?

>> So I mean exclusive open should really block _all_ following opens of
>> the device, exclusive or not.
>
> That will probably break a lot of stuff.

That would surely need a new flag like O_REALLYEXCL. :)

> I'm currently working on in-kernel media presence polling to handle
> the open and polling command sequence issues. ÂThat said, it's not
> entirely clear how the mount case should be handled. ÂIf a media is
> mounted, the device is exclusively open and media presence polling
> shouldn't be inserting commands in the middle but then how can it
> detect the media has been ejected by the user? ÂKay, can you please
> enlighten me on how it's supposed to work?

Non-optical devices should not be a problem, and can be always polled,
as it seems. We do this without O_EXCL since forever.

For optical drives I would never ever bypass O_EXCL, like udisks is
doing it. There are far too many problems with burning, which never
got really solved.

Force-removed media (not recommended unlocked doors) might not be
detected until the filesystem is cleaned-up/umounted, but that's
probably the better compromise than fiddling with the broken drives
during burning sessions.

Kay
--
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/