Hey,

On Sun, Jan 29, 2012 at 12:09 PM, Stef Bon <s...@bononline.nl> wrote:
> a. can the udisks mount monitor also provide this information to other
> apps, like dolphin and autofs.
> I see that lot's of apps/programs are "interested" in mountinfo, and
> poll/scan the mountinfo file for that purpose.
> Isn't it better to have one prog do that (==udisks) and others get the
> information  via a socket/dbus?

I think applications should just be reading /proc/self/mountinfo (or
similar if not on a recent Linux) themselves.

For the mounts that are block devices, udisks provides the mount
point(s) as a D-Bus property

 
http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Filesystem.html#gdbus-property-org-freedesktop-UDisks2-Filesystem.MountPoints

but that's not really a replacement for reading /proc/self/mountinfo yourself.

> b. does udisks also provide information about non local mounts (cifs,
> fuse etc) , so no disks?

Nope, udisks is only concerned with block devices and storage
devices... So, yeah, a file manager like Nautilus where you want to
show mounts from both storage devices and, say, NFS mounts will have
to look at /proc/self/mountinfo itself in addition to other sources
like udisks or whatever. (In GNOME 3.4, the
gvfs-udisks2-volume-monitor process does that and it presents the
information through the GVolumeMonitor/GDrive/GVolume/GMount APIs.)

> c. I've been thinking about the ability to make the kernel export
> mountinfo via netlink. Everytime the kernel mounts, a message is send
> via netlink to userspace. Doesn't it make the monitoring easier??? Now
> the whole mountinfo file has to be parsed, sorted and checked for changes.

I don't think so. I think the current approach with rereading
/proc/self/mountinfo whenever there's a change [1] is good enough. The
key here is to keep kernel<->userspace interfaces as simple as
possible.

Thanks,
David

[1] : See e.g. 
http://cgit.freedesktop.org/udisks/tree/src/udisksmountmonitor.c?id=1.91.0#n298
for one way to get notified when the file changes
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Reply via email to