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