KDE Volume Manager not receiving mount points from HAL - it can't cope!

Mon Sep 20 16:46:59 PDT 2004

[btw jump to the end for the conclusion if you like!]

On Mon, Sep 20, 2004 at 11:54:11PM +0200, David Zeuthen wrote:

> On Mon, 2004-09-20 at 22:32 +0100, Luke Kenneth Casson Leighton wrote:

> I'm not completely acquainted with how KDE handles storage devices today
> so I may be missing something.

 me too.

 from what i understand [of the latest cvs code which will end up in a
 version of kde greater than 3.3.0] there is:

 - some code that parses /etc/fstab and /etc/mtab
 - some more code that translates (guesses) AIX, BSD and Linux
   /dev entries into floppies, usb, disks, etc. by analysing
   the device name, and also having a #ifdef AIX compile-time switch
 - mountwatcher which reads /etc/fstab and /etc/mtab and determines
   a) the type of drive b) whether it's mounted.

 none of this is really great (from an abstraction point of view or
 from a user point of view for removable media) but it works so that
 _is_ great.

 KVM relies exclusively on information it receives from HAL.
 from an abstraction point of view, this is great - but it is
 missing information (e.g. the mount point of a removable device
 with no media!)

> 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. 

 ah, no i don't, that's the point: i _don't_!

 should i be using a later version of hal (than 0.2.97+cvs20040907)?

	Dumping 39 device(s) from the Global Device List:
	-------------------------------------------------
	udi = '/org/freedesktop/Hal/devices/block_8_16'
	  info.udi = '/org/freedesktop/Hal/devices/block_8_16'  (string)
	  storage.hotpluggable = true  (bool)
	  storage.removable = false  (bool)
	  info.product = 'USB-FDU'  (string)
	  info.vendor = 'Y-E DATA'  (string)
	  storage.drive_type = 'floppy'  (string)
	  block.storage_device = '/org/freedesktop/Hal/devices/block_8_16'  (string)
	  storage.physical_device = '/org/freedesktop/Hal/devices/usb_usb_device_57b_0_501_-1_noserial_0'  (string)
	  storage.vendor = 'Y-E DATA'  (string)
	  storage.model = 'USB-FDU'  (string)
	  storage.automount_enabled_hint = true  (bool)
	  storage.no_partitions_hint = true  (bool)
	  storage.media_check_enabled = true  (bool)
	  storage.bus = 'usb'  (string)
	  block.minor = 16  (0x10)  (int)
	  block.major = 8  (0x8)  (int)
	  info.capabilities = 'block storage'  (string)
	  info.category = 'storage'  (string)
	  block.device = '/dev/sdb'  (string)
	  info.parent = '/org/freedesktop/Hal/devices/scsi_1_0_0_0'  (string)
	  block.is_volume = false  (bool)
	  block.have_scanned = false  (bool)
	  block.no_partitions = true  (bool)
	  linux.sysfs_path_device = '/sys/block/sdb'  (string)
	  linux.sysfs_path = '/sys/block/sdb'  (string)
	  info.bus = 'block'  (string)

> 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), 

 well, there's part of my beef.

 HAL is supposed to provide a level of abstraction - i.e. to negate the
 need for #ifdef AIX, #ifdef BSD and #ifdef LINUX in the code.

 now, a program /etc/hal/devices.d/fstab-sync _that's_ a different
 matter.

> 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.

 ah, but how is a properly abstracted program KVM supposed to _know_ 
 what the mount point /media/floppy1 is?

 what i believe to be the way that this _should_ work is as follows:

 * user plugs in usb floppy, HAL reacts.

 * HAL runs /etc/hal/devices.d/ entries (e.g. fstab-sync)

 * fstab-sync not only enters information in /etc/fstab BUT ALSO
   it communicates to HAL information that needs to go into
   the UDI table.

   for example - the volume mount point (e.g. /media/floppy1)

 * HAL then notifies any programs listening (via udev) e.g. KVM
   "hey this device is now active, and its mount point is
    /media/floppy1".

 [and of course if you don't _like_ to mount the floppy on
  /media/floppy1 then you modify fstab-sync to get it to go
  somewhere else]

 the present situation is as follows:

 * user plugs in usb floppy, HAL reacts.

 * HAL runs /etc/hal/devices.d/ entries (e.g. fstab-sync)

 * fstab-sync not only enters information in /etc/fstab 

 * HAL then notifies any programs listening (via udev) e.g. KVM
   "hey this device is now active".

 * KVM must determine (and mountwatcher presently does this but KVM
   does not!), by reading /etc/fstab (in the case of there being
   a matching fstab-sync program), where the mount point is.

 this last step in the present situation is where the problem lies:
 KDE must now have a "matched" per-OS-specific version of fstab-sync
 and ALL OTHER programs that go into /etc/hal/devices.d/

 if for some unbelievable and implausible reason, HAL ever ends up on
 windows, and KDE gets compiled on windows, do you _really_ believe
 that someone will want to write code #ifdef WINDOWS in KDE source code
 _and_ also rewrite fstab-sync (or an equivalent program) to match that?

 adding _yet another_ #ifdef case, when HAL is supposed to be providing
 the a in abstraction?

 i do not believe so.

 _however_ it is perfectly reasonable to write a per-OS version or
 alternative to fstab-sync and for KDE (and Gnome) to rely exclusively
 on the information received from HAL.

 so.

 my question is:

 if i make a modified version of fstab-sync that runs, oh,
 say hal-set-property, or calls hal_device_set_property_string
 which adds in the volume.mount_point "/media/xxxxx1", what sort
 of caveats can i expect?

 for example, would the HAL code assume that because it's a floppy,
 all volume properties should be deleted, or something?

 for example, after fstab-sync is run, are all volume properties
 reset to defaults and then read from /etc/mtab?

 l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl at lkcl.net"> lkcl at lkcl.net </a> <br />

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal