autofs - automatic unmounting / syncing. how does HAL help?

[John (J5) Palmieri]

I would just like to say David is being modest.  HAL is the corner piece
of Fedora and is most likely going to be the same for every other distro
that wants dynamic handling of any hardware.  In the future it might
even take over some of the tasks that were traditionally left to Kudzu.
HAL basically does things the "right way" and where it doesn't it
provides a central place to be fixed instead of searching for probing
code all over a distro.  It also separates out policy so it makes it
easier to maintain and tweak behavior in the long run.  So if you are
asking should you move to hal then the answer is yes.  We seem to think
it is mature enough and while I can't speak to how Debian and Novell
people feel they both have people working on it and integrating it into
their distros.  KDE seems to be moving towards it and Gnome has
sanctioned g-v-m as a component of 2.8.0 which brings in the dbus and
hal dependencies.  In other words it is looking like it will become a
pervasive technology on Linux so why not use it and help make it better.

On Thu, 2004-09-16 at 19:23 +0200, David Zeuthen wrote:
> On Thu, 2004-09-16 at 18:13 +0100, Luke Kenneth Casson Leighton wrote:
> > okay.
> > 
> > the reason why i am abandoning my hacked-up version of usbmount, most
> > of which i moved into an autofs script /etc/auto.usb.sh, is because
> > of integration with the desktop.  and i was getting into a muddle.
> > 
> 
> For some background of HAL see the spec in the doc/spec directory.
> There's a recent version here
> 
>  http://freedesktop.org/~david/hal-spec/hal-spec.html
> 
> > the issue(s) are:
> > 
> > - usb floppies and usb card readers tend to get left plugged in
> >   permanently, whilst the media on them is arbitrarily removed.
> 
> HAL does this; we poll the devices (but have a blacklist for problematic
> devices such as pcmcia-cs, Zip drives etc.).
> 
> > - it's NOT reasonable to expect users to cope with "oo you have
> >    to run umount" - they just won't care.
> > 
> 
> Of course users won't care. Now, the hal daemon does a 'umount -l' and
> emits what we call a DeviceCondition so the desktop may choose to deal
> with it to e.g. put up a dialog telling off the user. 
> 
> (GNOME Volume Manager doesn't do this right now; not sure about KDE
> Volume Manager)
> 
> > - some usb pendrives, some usb floppies, and also some usb card
> >   readers, will either have a partition on them (/dev/sda) or
> >   they may have a partition table (/dev/sda[1-4]).
> 
> HAL detects this and deals with it.
> 
> > - usbmount _was_ smart enough to read /sys in order to determine
> >   partition information should it be there (so i was able to
> >   create an fstab-equivalent for the autofs.usb.sh script to
> >   parse and understand...
> > 
> > - ... but of course that doesn't help you for a usb removable
> >   media which might happen to have a partition on it, it might
> >   happen to have a partition table, you won't know until the
> >   media is plugged in and tested.
> > 
> 
> We probe the media in HAL for filesystems; both partitions and the main
> block device. We also retrieve labels and UUID if applicable.
> 
> >   usbmount made the assumption that there might be one or
> >   the other, but only one partition (ultimately) and used
> >   "/sbin/fdisk" to check (!)  you ended up with either /dev/sda
> >   or /dev/sda1 (but never /dev/sda[1-4]).
> > 
> > so.
> > 
> > i understand that HAL captures hotplug events from usb card reader
> > "media insert" events, is that correct?
> > 
> 
> There are no media insert events - you will have to poll; no question
> about it. In general USB storage devices are cheap junk that doesn't
> have the logic to even emit a media change event so the kernel has no
> chance to capture it. See the linux-hotplug archives from Jan-May 2004
> for some discussion.
> 
> > because if so (and usbmount certainly couldn't cope with that)
> > then part of the problem is solved: media in, redo entries,
> > notify KVM, off we go.
> > 
> 
> This is basically what HAL does.
> 
> > this still leaves two issues outstanding:
> > 
> > 1) how can HAL help with automatic unmounting?
> > 
> 
> Well, we do the umount -l in the hal daemon. We really have to (even
> though it may smell like policy) because the hardware/media is indeed
> gone.
> 
> >    should this be hacked into KDE?
> > 
> 
> Someone is already working on the KDE Volume Manager. One explicit goal
> of HAL is to get wide adoption and get all the key desktop projects
> (KDE, GNOME, OO.o, Mozilla, Java, Mono, ...) to use it. That's in part
> why HAL is hosted on freedesktop.org.
> 
> Presently I'm working on a libhal-storage library so you can say 
> 
>  name = hal_drive_get_displayable_name(hal_drive)
> 
> such that e.g. GNOME and KDE displays the same name of the drive. Share
> policy and stuff.
> 
> >    should i continue to investigate autofs?
> > 
> 
> Well, HAL pretty much does all that autofs does as well as a quite a few
> more things like emitting signals over D-BUS, it's well-documented,
> provides an abstract view of the hardware (also other hardware like
> networking, input devices, multimedia devices etc.)
> 
> Also, we're always looking for more hackers :-)
> 
> >    should i write an /etc/hal/device.d/autofs-update.hal
> >    script that mirrors what fstab-update.hal does?
> > 
> 
> I assume you mean fstab-sync that is invoked as a hal callout.
> 
> > 2) usb floppies: these definitely don't generate usb hotplug
> >    notify events (mine doesn't... just checking.... nope!)
> > 
> 
> We'll hal handles these (modulo bugs in hal)
> 
> > help help i need to get something working - fast!
> > 
> 
> Well, HAL is pretty much designed to cope with all this and it works
> pretty well most of the time. It's a pretty young project (I started it
> about one year ago) but distributions like Fedora and Debian have
> already picked it up. When it doesn't work we usually fix the bugs
> pretty fast.
> 
> Cheers,
> David
> 
> _______________________________________________
> hal mailing list
> hal at freedesktop.org
> http://freedesktop.org/mailman/listinfo/hal
-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com

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