[patch] progress with autofs.

[David Zeuthen]

On Fri, 2004-09-24 at 10:34 +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Sep 24, 2004 at 02:37:52AM +0200, David Zeuthen wrote:
> > 
> > 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. 
> 
>  well, the changes are pretty minimal: about 98 to 99% of the code is
>  identical between fstab-sync and fstab-sync-doing-autofs.
> 
>  a few tweaks to read and write parameters in a different order
>  to cope with /etc/auto.hal instead of /etc/fstab, replacing
>  FSTAB_SYNC_ROOT_PATH with a char* which is initialised in
>  main(), that sort of thing.
> 
>  very very obvious non-impacting changes.
> 
>  about the only one with any "complexity" is that i'm going to have to
>  read the /etc/auto.hal file in order to determine the mountpoint and to
>  always always always add a "volume.automount_point" into the HAL
>  database rather than bombing out just because the mountpoint entry
>  happens to already be in /etc/auto.hal.
> 

Ok, so the callout (fstab-sync or, as I like it, autofs-sync) writes
this property. I think that is OK.

> > Just separating functionality. 
> 
>  if you're happy to have two near-identical programs, fstab-sync.c
>  and autofs-sync.c, fine.
> 
>  i can if you like split out the common code into a library, but to be
>  honest i don't think it's worth the effort: 98% of the code presently
>  in fstab-sync.c would end up in the library.
> 

I think it actually may be a nice thing this ends up in a library or
some other shared facility - I'm taking you refer to the functions for
dealing with FSTable* structures. Btw, the Volume struct in fstab-sync
will go away soon; will be replaced by code now in libhal-storage. Also,
my current plans involve deleting some of the code from fstab-sync that
helps determine the mount point candidate - this will live in the
libhal-storage library; e.g. there will be a function 

char *
hal_volume_policy_compute_mountpoint(HalDrive *drive, HalVolume *volume,
                                     HalStoragePolicy *policy)

where users can tweak the policy by modifying the policy object. So,
fstab-sync will read a file with rules and build the policy object and
then just call this function. Specifically, other things than fstab-sync
can use this. 

I'm hoping to land these changes some next week - from fstab-sync point
of view it's mostly cleanups really. For libhal-storage, there's some
new features.

I'm guessing the easiest thing at first is to move all the code that can
be shared in a single .[ch] file pair and share that between the two
binaries fstab-sync and autofs-sync.

>  ... if i were to take the autofs "script" approach and use
>  /etc/auto.hal.sh instead, then i would revert some of the changes and
>  make /etc/auto.hal.sh read an fstab-formatted file instead of an
>  autofs-style one.
> 
>  so there would be even _less_ differences!
> 

I think this may be even nicer actually; you script could even query hal
for details; e.g. if someone (say, K3B or nautilus-cd-burner) has a lock
on the cdrom drive you never mount the disc.

This might in fact be the best option?
 
> > 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? 
> 
>  yes, they are minimalistic, and also i'm suggesting additions to the
>  hal db format so that the impact on expectations of userspace programs
>  is even less.
> 

I'm all open for adding properties as long as we don't change existing
ones; what I'm not terribly excited about is adding a lot of code that
deals with policy because the hal daemon needs to stay out of policy. 

We do kind of support the old UNIX dogma with volume.is_mounted and rely
on /etc/mtab to update this one. How about this:

 1. hal callout autofs.hal sets the boolean property
    volume.is_managed_by_autofs to TRUE and the string property
    volume.mountpoint to where we can access the volume. It also sets
    volume.is_mounted to TRUE

 2. The hal daemon respects the volume.is_managed_by_autofs and thus
    doesn't update the volume.mountpoint, volume.is_mounted properties

 3. The auto.hal.sh script maintains the boolean property
    volume.is_safe_to_remove with when the volume can be safely removed

 4. The auto.hal.sh script respects if a drive is locked and this wont
    physically mount the volume (the K3B, n-c-b issue above)

>  i think it necessary that volume managers explicity code in support for
>  autofs-managed partitions.

Well, if they're autofs-managed there is no need for a desktop program
to mount the volume :-).

Ideally, what I like to see is completely unchanged HAL API from the
desktop point of view; e.g. programs can rely on volume.is_mounted and
volume.mountpoint. What happens beneath the hood they need not care
about. 

This is not saying they shouldn't support optional properties - e.g. a
filemanager might displaying a bouncing bomb on top of a volume when
volume.is_safe_to_remove exists and it is false.

David


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