[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Procedure on mounting USB/hotplug devices



Ok, after reading through several man pages, I got some answers (but not all) 
to my own questions...

On Monday 06 August 2007 21:40, Marko Vojinovic wrote:
> As far as I understand the procedure so far, there are several steps
> involved (please correct me):
>
> 1) The device gets plugged in. The USB hardware sees it and sends an
> interrupt. This gets to the kernel.
> 2) The kernel examines the details of the device, loads appropriate modules
> and instructs udevd (or is it hal?) to create a device node in /dev. This
> gets logged in /var/log/messages.

The kernel signals udevd to create a node.

> 3) Then udevd (or hal? or what?) creates the device node, and also logs
> this in /var/log/messages. After that, it sends a signal to the next
> service that there is a new device node attached (is this true?).

The signalling is done (afaiu) through dbus-daemon, aka messagebus service.
It is supposed to be running. The daemon which receives the signal should be 
hald.

> 4) This next daemon/service (which one??? autofs?) catches this signal,
> reads off the device's label (if it has one), creates a new directory named
> /media/label and modifies /etc/fstab accordingly so that /dev/device can be
> mounted to /media/label. It also sets the permissions in some way (how???
> where does one configure them?). It then sends a signal to a
> possibly-working service in a desktop environment (KDE or Gnome) that there
> is a new device to be mounted.

Ok, this is wrong. First, the /etc/fstab is no longer autoupdated. Hal reads 
off the properties for the device (label, filesystem, partition table, etc.), 
assigns everything else that should be known (mount point, permissions, 
ownership, etc.), and writes it down in it's own database. It does not 
actually create a mount point.

After that, it should signal to "something" that there is a new device to be 
mounted. What is this "something"?

> 5) The appropriate DE service gets that, invokes "mount /media/label" (or
> gnome-mount? is that DE-dependant? what if there is no DE running, just a
> WM like WindowMaker? or no X at all?), and after the mount, it puts an
> appropriate icon on the desktop where a user can "click" to open a file
> manager and read/write the data or whatever.

The "DE/no DE" situations seem to differ.

If there is a DE running, this "something" catches the signal, internal gears 
and wheels of DE start clicking, and eventually the device gets mounted using 
the hal database. A file manager is opened, and everyone is happy. In case of 
Gnome, the gnome-mount does the work (creates a mount point, reads off the 
data from hal, mounts the device), and it is called upon from 
gnome-vfs-daemon and/or gnome-volume-manager and/or other gnome-* stuff. As 
for KDE, the same thing happens, only with some other tools doing the work 
(which ones?).

However, if there in *no* DE running, **nothing happens**. The device does 
*not* get mounted automatically, and one has to go about creating the mount 
point manually, and doing

# mount -t something /dev/something /media/something

by hand, in order to mount the device. After that, only root has access to the 
data (without further hassling), and everyone is *not* happy.

So, which service should be doing this instead of me?

Best, :-)
Marko

Marko Vojinovic
Institute of Physics
University of Belgrade
======================
e-mail: vmarko phy bg ac yu



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]