[patch] progress with autofs.

[Luke Kenneth Casson Leighton]

okay, um, well, i'm making progress.

i've had to do a few major "if (automount)..." additions and logic
changes.  um.

also i think it quite sensible to create a _separate_
"volume.automount_point" because it allows KVM and GVM to distinguish
the mount point from an ordinary one.

plus, you actually _need_ to know where the automount point is _going_
to be as distinct from where it really is.

plus, by putting the automount point into a separate HAL database entry,
the existing logic is not interfered with.

things to fix:

fstab-sync [in automount mode] presently exits if it detects
that the entry in /etc/auto.hal already exists: what _i_ need
is that the entry "volume.automount_point" be put in the HAL
database (by fstab-sync) even if that is the case.

if HAL was terminated with prejudice, leaving behind the entries in
/etc/auto.hal because fstab-sync was never called with an -r, or for
any other reason something goes pear-shaped....

so, the call to add volume.automount_point is done BEFORE the check
for the entry already being in /etc/auto.hal, which introduces
a race condition in the unlikely event of someone else modifying
/etc/auto.hal.

i just realised that i have a bug in fstab-sync wrt when there already
exists an entry in /etc/auto.hal - i need to do a lookup of the udi
being added, see if it's already in /etc/auto.hal, and if so, set the
matching auto.hal mountpoint as volume.automount_point.

when i've fixed that i will send in some patches.

anyway.

this is a rough guide to the logical sequence of events for
autofs-enhanced HAL and fstab-sync:

1) hal gets hotplug events, adds device, calls fstab-sync

2) fstab-sync checks entry in /etc/auto.hal, which places an entry
   in the DEVICE block "volume.automount_point" maybe this should be
   called block.automount_point, hm.

3) after fstab-sync exits, hal picks up the volume.automount string and
   sends a VolumeMount notification via dbus WITH THIS STRING.

   if anyone can think of a better way to do this i'd love to hear it.

   the mount point information is *not* going to come from /etc/mtab
   on-demand.

   and it's also not really going to come from KVM or GDM because, hey,
   the mountpoint directory doesn't actually exist with autofs, it
   only exists _after_ you access it!

4) polling takes place in hal, hal discovers a volume: it copies the
   volume.automount_point string FROM THE PARENT into the volume.

   volume.mount_point and all functionality related to
   volume.mount_point has NOT BEEN ALTERED IN ANY WAY
   (including /etc/mtab stuff)

5) polling continues to take place, hal finds a volume has gone: it gets
   deleted, normal manner.

   parent's volume.automount_point database entry is STILL THERE.
   so a repeat of 4 will result in the automount point being picked up
   again.


the existing functionality and state machine is not altered.

what i am tying autofs into effectively is the volume discovery and
removal by HAL.

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