[patch] progress with autofs.
David Zeuthen
david at fubar.dk
Thu Sep 23 17:37:52 PDT 2004
Hi,
In my view it would really be better if there was a dedicated callout
modifying /etc/auto.hal rather than putting this functionality into
fstab-sync. Just separating functionality. Btw, fstab-sync is completely
optional since it's enforcing policy. If I understand correctly Ubuntu
doesn't use fstab-sync, rather they rely on pmount (see the utopia-
list at gnome.org archives from July or August for details).
So, what I'm thinking is that this is just a third way to enforce policy
using hal. Hence, why I like the separation. Also, the changes to hald
seems to be pretty minimalistic, if any, given your message below, is
this correct? It would be good to have a configure option to turn this
on and off.
Thanks,
David
On Fri, 2004-09-24 at 01:38 +0100, Luke Kenneth Casson Leighton wrote:
> 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.
>
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list