On Tue, Mar 1, 2011 at 12:55, Karel Zak <k...@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.siev...@vrfy.org> wrote: >> > On Fri, Feb 25, 2011 at 14:47, PCMan <pcman...@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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
