KDE Volume Manager not receiving mount points from HAL - it
can't cope!
David Zeuthen
david at fubar.dk
Mon Sep 20 14:54:11 PDT 2004
On Mon, 2004-09-20 at 22:32 +0100, Luke Kenneth Casson Leighton wrote:
> i'm messing with HAL hal-0.2.97+cvs20040907$ and with KVM and kde from
> latest cvs.
>
> the issue is that a usb floppy drive has a mount device of /dev/sda
> and a mount point generated in ftsab /media/floppy1 that isn't then
> passed over by HAL to KVM.
>
> KVM goes "oh, it's a floppy, and we don't know its mountpoint, hmmm"
> and generates a filename "floppy:/" for it.
>
> when a user accesses the Floppy, KDE goes "floppy:/" ah ha, i know what
> to do with that, let's go access /dev/fd0 which just smells of cow poo
> because the actual location is /dev/sda.
>
> lshal shows no entries, in fact, looking at block_class_device.c
> i find that it reads /etc/mtab quite happily.
>
>
> under the normal KDE system (mountwatcher, disabling KVM) it
> works great because mountwatcher reads /etc/mtab and /etc/fstab
> and wow, gosh, other than the problem of forcing the users to
> deal with an "unmount" concept, somewhere under the hood KDE
> goes "oh, this is /dev/sda, and it's /media/floppy1, and it
> isn't mounted, so let's mount it".
>
> ... but i don't _want_ to use mountwatcher because then i would
> have no chance to have a CD or DVD or camera be fired up automatically
> from a hotplug event.
>
>
> so.
>
> is the solution that i should hack KVM to read /etc/fstab?
>
> should i hack KVM to read /etc/fstab?
>
> should i hack HAL to write an /etc/autofs.hal file and hack KVM
> to read it?
>
> should i hack the KDE source (kioslaves/devices/kdemodule)
> to blop the functionality of KVM into the kdebase mountwatcher?
>
I'm not completely acquainted with how KDE handles storage devices today
so I may be missing something.
As the hal daemon polls for media on USB floppy drives you'll get a new
hal device object of capability 'volume' precisely when there is floppy
disk in the the drive. This hal device object is a child of the hal
device object representing the drive itself. It works just like when
using partitioned media, e.g. /dev/sdb and /dev/sdb1 on a memory card.
One of the points of hal is to abstract the difference between
partitioned and non-partitioned media; e.g. provide an abstraction with
drives and volumes instead.
So, when you mount the volume using mount(1), e.g. 'mount /dev/sda' from
the commandline or from a program like KVM (since an entry
relating /dev/sda and /media/floppy1 is already in /etc/fstab file this
is possible), the property volume.mount_point on that hal device object
will be set to the mount location (as HAL watches the /etc/mtab file) if
the mount succeeds.
Since the volume.mount_point property changes from "" to e.g.
"/media/floppy1" the hal daemon emits a signal over D-BUS that you can
catch with either libhal (as a callback) or using the Qt bindings for
libdbus. So, I guess one way is to just wait for the mount point from
hal to appear on the hal device object representing the volume in the
floppy drive?
Btw, for e.g. x86 legacy floppy drives (but also other storage devices
that can't be polled, e.g. some Zip and LS120 drives) the hal daemon
doesn't poll for media (well, you can make it do it but it's noisy :-)
so you only get the volume hal device object only when the floppy is
mounted. So everything here will still work as excepted, except that you
can't do automounting.
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list