Gnome-2.18: Ejecting CD/DVD ROMs

Dan Nicholson dbn.lists at gmail.com
Wed Jul 25 19:19:12 PDT 2007


On 7/25/07, Randy McMurchy <randy at linuxfromscratch.org> wrote:
> Dan Nicholson wrote these words on 07/25/07 18:21 CST:
>
> > I think you actually need the `eject' program. It's a runtime dep for
> > HAL on Linux. It's called by /usr/lib/hal/hal-storage-eject, which is
> > used by the Eject method.
>
> I get it now. Thought it's said in the gnome-mount docs that:
>
> "The grand plan with gnome-mount is to get the appropriate GNOME
> software (such as gnome-volume-manager and gnome-vfs) to use this
> instead of invoking mount(1)/umount(1)/eject(1) / invoking methods on
> HAL directly."
>
> I got confused with that and thought that gnome-mount actually did
> the work. I suppose gnome-mount/gnome-volume-manager simply adds
> some wrappers to the HAL routines so the operations don't need
> root privileges. I must admit I'm weak in this area.

Right. `eject' is a pretty simple program. I would have actually
thought that hal would just have its own implementation, but I guess
not. Although, hal does do the unmounting before hand, so all eject is
doing is truly ejecting (opening/closing tray, etc.). I think part of
the reason for calling the eject binary is that it's implemented on
FreeBSD (Solaris too?), so there's some platform independence they
don't have to recreate.

> Dan, care to write a paragraph that describes the relationship
> between
>
> HAL - gnome-mount - gnome-volume-manager

I thought I understood it really well, but a little experiment I did a
month or so ago meant something wasn't working quite as I expected.
But, for the most part, I think I know how they work.

HAL knows about how to mount and umount filesystems. The idea is to
have HAL perform these actions since more policy and dynamic things
can be handled there than just calling mount(8).

At the next level, in order to make the call to HAL to do the mounting
there's another level of abstraction with gnome-mount. This does stuff
like handling per-user mount flags and mount points. It also handles
the actual dbus call to HAL. The idea here is that if something in the
desktop session wants a filesystem mounted, it should execute
gnome-mount to handle all the details. This happens in gnome-vfs and
gnome-volume-manager. An important point here is that it may still get
denied when calls the Mount method (or Eject method in this case) on
the HAL bus. There can be system wide HAL policy that says "this
volume is not mountable" or "only these people can mount stuff".

In the desktop session, we have gnome-volume-manager, which calls out
to gnome-mount when signals show up on the HAL bus that a new volume
has been attached. You may notice in GNOME that if automounting fails
(for whatever reason), you can browse the Computer node and force a
mount. This is actually gnome-vfs calling out to gnome-mount.
gnome-volume-manager is sort of a glorified preference manager where
you can say what you want to happen in GNOME when certain hardware is
added. David Zeuthen (the HAL dev) has said that it should be called
gnome-hardware-manager since it does much more than just manage your
volume prefs.

So, in the typical case where you've just inserted a USB stick, the
process goes something like this:

- HAL receives hardware event, constructs some data on it, and sends
it out on the org.freedesktop.Hal bus

- gnome-volume-manager (g-v-m) sees this event on the bus. Since this
is a removable volume, it checks to see that the user wants to mount
them. The user does.

- g-v-m executes gnome-mount. gnome-mount checks the user's per-volume
prefs in GConf and builds up a method call for Hal. It calls the Mount
method on the org.freedesktop.Hal.Volume bus and checks for errors
returned from Hal.

- gnome-mount returns status to g-v-m. g-v-m carries out any other
actions it needs given success or failure of the mount.

A similar chain of events happens when you remove the USB stick. There
gnome-mount calling the Eject method causes /usr/bin/eject to be
called by HAL.

I thought gnome-mount also handled the case of reading fstab (there's
code for it). I got a permission denied error, which I know comes from
HAL, which assumes that if a volume is listed in fstab, mounting
shouldn't be handled by HAL. But I can see the code in gnome-mount
where it calls mount(8) instead of HAL in the event that it sees the
device or mount point in fstab. I didn't work for me, though.

> Right now the text on the gnome-mount page is wrong and we need to
> fix it.

I'm not sure what the best thing to say about its purpose is. I
suppose its main two virtues are that it hides mounting details from
the desktop (e.g. gnome-vfs) and that it integrates with the
system-wide policy defined in HAL.

That was probably way longer than it needed to be. I think I'm one of
those people that learns by saying (or typing) things, and that was
something of a refresher for me.

--
Dan



More information about the blfs-dev mailing list