On Mon, Mar 17, 2008 at 8:21 PM, Aharon Schkolnik <[EMAIL PROTECTED]>
wrote:
> I guess I don't really understand either.
:)
>
> In any event, my burner is not a USB device, so I don't think udev would
> be
> changing the permissions on it.
>
> Anyone care to comment on that assumption ?
Well, see for instance /etc/udev/persistent.rules on my Debian Etch
desktop:
KERNEL=="sg*", ATTRS{type}=="8", ENV{ID_SERIAL}=="", \
IMPORT{program}="scsi_id -g -x -s $devpath -d $tempnode"
KERNEL=="sg*", ATTRS{type}=="8", ENV{ID_SERIAL}=="", \
IMPORT{program}="scsi_id -g -x -a -s $devpath -d $tempnode"
("sg" being conventional generic SCSI device names).
So udev is not limited to usb devices only. It "owns" the entire /dev
directory.
>
> From the udev-faq:
>
>
> Q: Can I use udev to automount a USB device when I connect it?
> A: Technically, yes, but udev is not intended for this. All major
> distributions
> use HAL (http://freedesktop.org/wiki/Software_2fhal) for this, which
> also
> watches devices with removable media and integrates into the desktop
> software.
>
> So, it seems that HAL would be the one taking care of the removeable
> media in
> the burner.
>
The way I understand this, "HAL" (Hardware Abstraction Layer) provide the
information and sends triggers over a data bus to other programs when it
changes. It also maintains a database of "current" devices.
Udevd is just one subscriber to these messages and this is how it finds
about new/removed devices, but both HAL and udevd are not limited to
removable media - see an excerpt from the output of "lshal" on my desktop:
udi = '/org/freedesktop/Hal/devices/acpi_CPU1' (i.e. HAL lists the CPU
itself, which is not dynamically changeable on this system).
Cheers,
--Amos
