[udisks] CD-ROM polling failed due to O_EXCL flag (poller.c)

[Kay Sievers]

On Tue, Mar 1, 2011 at 12:55, Karel Zak <kzak at redhat.com> wrote:
> On Sat, Feb 26, 2011 at 04:53:16PM +0800, PCMan wrote:
>> Thanks for the suggestions.
>> I made a new patch reading from /proc/self/mountinfo as suggested by you.
>> In addition, no code is taken from HAL so there is no license issue now.
>> Please review the patch attached to this mail.
>>
>> On Sat, Feb 26, 2011 at 12:12 AM, Kay Sievers <kay.sievers at vrfy.org> wrote:
>> > On Fri, Feb 25, 2011 at 14:47, PCMan <pcman.tw at gmail.com> wrote:
>> >> I made a small patch against the latest udisks in git after hacking HAL daemon
>> >> and it works. Please review the patch. Thanks a lot.
>> >>
>> >> https://bugs.freedesktop.org/attachment.cgi?id=43798&action=edit
>> >
>> > mtab is officially dead now, even in mount(8). Please always use
>
>  well, it's experimental death :-)

Systemd relies on it to be finally dead. :)

>> > /proc/self/mountinfo, it has the major/minor in there, which is a far
>> > more reliable match than the device file name. Example is here:
>
>  are you sure?

Yeah, in the usual case, yes. The device that shows up for btrfs is
just random, and in most cases only one of several.

>  major/minor numbers are not reliable with btrfs (at least on
>  2.6.35.6-45.fc14.x86_64), btrfs uses some funny dev_t numbers:

Btrfs is like a network filesystem, it has no backing device.

>    # ll /sys/dev/block/0\:37/
>    ls: cannot access /sys/dev/block/0:37/: No such file or directory

Major == 0 means, there is no device, and no device node ever.

>  I hope this all is a bug, because I cannot imagine distribution that
>  uses FS with these "features".

There is no old-school solution for that problem right now. Userspace
needs to handle it somehow. We need to handle modern filesystems,
which do no fake block devices, but just behave like a simple network
filesystem mount.

We probably need a filesystem specific ioctl, to return the list of
real devices, or we we need  a statfs()-like call which can do that.

The O_EXCL handling can just fail here, it's only needed for optical
media, which does not have these filesystems for now. There is no real
harm in opening any device which isn't busy with an optical media
burning session.

With the switch to in-kernel polling, this all should go away anyway.

Kay