UDEV vs. HAL responsability
Martin Pitt
martin.pitt at ubuntu.com
Thu Jul 5 08:04:02 UTC 2007
Hi Paul,
Paul Dufresne [2007-07-04 16:27 -0400]:
> Basically, the question that come to my mind is about
> /etc/udev/rules.d/45-libgphoto2.rules .
> I am not even sure but I think most entries in there is making in sort
> that camera devices
> get mounted automatically.
Not precisely. Cameras which behave like a drive ("mass storage") are
already handled by the existing hal magic. Those rules are for cameras
which do *not* provide mass storage interface, but need to be talked
to through libgphoto. This library steers the cameras with their
proprietary protocol (or the more modern PTP standard) and uses the
raw USB device.
For this, the raw device needs to be readable and writable for normal
users, to avoid running gthumb and friends as root.
Managing the permissions of /dev/... nodes is udev's responsibilities,
thus using udev rules for this case is correct.
> And that it requires to add a line for any known camera devices.
Fortunately most modern cameras are covered by
PROGRAM="check-ptp-camera 06/01/01", MODE="0660", GROUP="plugdev"
i. e. cameras which support the Photo Transfer Protocol standard. The
others really need to be maintained manually by vendor/product ID. A
nuisance, I know, but there is no property which you can tell from the
USB bus that identifies a device as a camera.
> Would it be possible to do the same with HAL?
Not for managing the device permissions, see above.
However, libgphoto's postinst does not only create the udev rules
file, but also
/usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi
which tells hal about the capabilities of these cameras. This enables
the desktop magic for handling cameras (like telling g-v-m that it
should run gthumb when you plug in a camera).
So, summary:
udev: manage /dev permissions
hal: provide device info for desktop integration
Both are independent things, and I believe that the current structure
is correct (it's not pretty, of course, but that's not something we
can change; hardware sucks :-) ).
I hope I could shed some light on this.
Thanks,
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
More information about the Ubuntu-devel-discuss
mailing list