[patch] progress with autofs.
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Sep 23 17:38:12 PDT 2004
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
More information about the Hal
mailing list