Discussion:
removal of support for /etc/hotplug/usb/
(too old to reply)
Marco d'Itri
2005-09-15 10:30:20 UTC
Permalink
After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
subsystem. This is scheduled to happen next month, when most of the
current hotplug package will be replaced by a new coldplug program
which will be part of udev.

While udev provides and currently enables by default an helper program
to maintain compatibility with /etc/hotplug.d/, no such program exists
for map files and I do not think it would be useful to write one
(conversion to hotplug.d scripts would be easier).

This means that the following packages will have to convert their map
files to udev rules files. Please remember that rules files MUST NOT be
installed in /etc/udev/rules.d/ but in /etc/udev/, and packages should
create symlinks to rules.d/ only when installed for the first time and
never again.

If you want to keep support for 2.4-based systems which can only use the
old hotplug package then you will need to convert your script to an
hotplug.d script, but please remember that future versions of udev will
disable by default processing of hotplug.d and dev.d.

Let me know if you have any questions or need help to fix your package.
Many of the scripts can be replaced with an udev rule to set the
appropriate permissions or directly start/stop the relevant daemon, I
added some comments below for a few packages which I checked.

The affected packages are:

libgpib-bin
bluez-bcm203x
eagle-usb-utils
eciadsl
gpsd
hpoj
pmp-common
kino (just run killall or start-stop-daemon from the rule)
libgphoto2-2 (should use a proper rule to change the permissions)
nut-usb
kcontrol (should use a proper rule to change the permissions)
libnjb-hotplug
openct
sl-modem-daemon
--
ciao,
Marco
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andrew Pollock
2005-09-15 11:00:33 UTC
Permalink
Post by Marco d'Itri
After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
subsystem. This is scheduled to happen next month, when most of the
current hotplug package will be replaced by a new coldplug program
which will be part of udev.
While udev provides and currently enables by default an helper program
to maintain compatibility with /etc/hotplug.d/, no such program exists
for map files and I do not think it would be useful to write one
(conversion to hotplug.d scripts would be easier).
This means that the following packages will have to convert their map
files to udev rules files. Please remember that rules files MUST NOT be
installed in /etc/udev/rules.d/ but in /etc/udev/, and packages should
create symlinks to rules.d/ only when installed for the first time and
never again.
If you want to keep support for 2.4-based systems which can only use the
old hotplug package then you will need to convert your script to an
hotplug.d script, but please remember that future versions of udev will
disable by default processing of hotplug.d and dev.d.
Let me know if you have any questions or need help to fix your package.
Many of the scripts can be replaced with an udev rule to set the
appropriate permissions or directly start/stop the relevant daemon, I
added some comments below for a few packages which I checked.
libgpib-bin
bluez-bcm203x
eagle-usb-utils
eciadsl
gpsd
hpoj
pmp-common
kino (just run killall or start-stop-daemon from the rule)
libgphoto2-2 (should use a proper rule to change the permissions)
nut-usb
kcontrol (should use a proper rule to change the permissions)
libnjb-hotplug
openct
sl-modem-daemon
And using the very funky dd-list, gives us a potentially more useful list:

Eduard Bloch <***@debian.org>
sl-modem

Paul Brossier <***@debian.org>
kino

Debian Qt/KDE Maintainers <debian-qt-***@lists.debian.org>
kdebase

Eric Dorland <***@debian.org>
openct

Edd Dumbill <***@debian.org>
bluez-utils

Shaun Jackman <***@debian.org>
libnjb

Robert Jordens <***@debian.org>
gpib

Tilman Koschnick <***@subnetz.org>
gpsd

Cyril Martin <***@free.fr>
eagle-usb

Frederic Peters <***@debian.org>
libgphoto2

Mark Purcell <***@debian.org>
hpoj

Arnaud Quette <***@debian.org>
nut

Joe Wreschnig <***@debian.org>
pmp-common

Marco d'Itri <***@linux.it>
eciadsl

regards

Andrew
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Shaun Jackman
2005-10-10 19:40:13 UTC
Permalink
I haven't found a great sysfs node to use for Creative Labs devices.
This is the best I've found so far:
$ udevinfo -ap /sys/bus/usb/devices/1-2.3/1-2.3:1.0
...
looking at class device '/sys/bus/usb/devices/1-2.3/1-2.3:1.0':
SUBSYSTEM="unknown"
SYSFS{bAlternateSetting}=" 0"
SYSFS{bInterfaceClass}="dc"
SYSFS{bInterfaceNumber}="00"
SYSFS{bInterfaceProtocol}="b0"
SYSFS{bInterfaceSubClass}="a0"
SYSFS{bNumEndpoints}="04"
SYSFS{modalias}="usb:v0471p0222d0100dcDCdsc00dp00ic*isc*ip*"

Is this the correct place from where to start writing a udev rule?

Cheers,
Shaun
Post by Marco d'Itri
After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
...
...
Post by Marco d'Itri
libnjb-hotplug
...
Shaun Jackman
2005-10-10 20:10:09 UTC
Permalink
The udev rule I've written for the Creative Labs Nomad Jukebox looks like this:

SYSFS{modalias}="usb:v0471p0222*", NAME="njb%n", GROUP="audio", MODE="0666"

udevtest seems to indicate some success:

$ udevtest /sys/bus/usb/devices/1-2.3/1-2.3\:1.0/
version 056
looking at '/bus/usb/devices/1-2.3/1-2.3:1.0/'
opened class_dev->name='1-2.3:1.0'
configured rule in '/etc/udev/rules.d/nomad.rules[1]' applied,
'1-2.3:1.0' becomes 'njb%n'

When I plug the device in, the node doesn't actually seem to be created though:

$ find /dev /sys -name \njb*
$

I would like the /proc/bus/usb node to be symlinked to /dev/njb%d,
with the correct permissions applied, as well as loading the "fuse"
kernel module. Is this possible?

Cheers,
Shaun

2005/10/10, Shaun Jackman <***@gmail.com>:
...
Post by Shaun Jackman
SYSFS{modalias}="usb:v0471p0222d0100dcDCdsc00dp00ic*isc*ip*"
Is this the correct place from where to start writing a udev rule?
Cheers,
Shaun
Post by Marco d'Itri
After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
...
...
Post by Marco d'Itri
libnjb-hotplug
...
Marco d'Itri
2005-10-10 21:10:14 UTC
Permalink
On Oct 10, Shaun Jackman <***@gmail.com> wrote:

(I hope this fully covers the changes needed.)
Post by Shaun Jackman
SYSFS{modalias}="usb:v0471p0222*", NAME="njb%n", GROUP="audio", MODE="0666"
It would work, but is wrong. If it were a block device you could use:

BUS=="usb", SYSFS{idVendor}=="0471", SYSFS{idProduct}=="0222", \
SYMLINK+="njb%n", GROUP="audio"

(There is no point in changing the group of a world-writeable device,
and the default is MODE="0660".)
Post by Shaun Jackman
$ find /dev /sys -name \njb*
$
But it appears that your package is an user space driver which uses
Post by Shaun Jackman
I would like the /proc/bus/usb node to be symlinked to /dev/njb%d,
with the correct permissions applied, as well as loading the "fuse"
kernel module. Is this possible?
There is no point in creating symlinks, because libusb does not care.
The current kernels only provide the /proc/bus/usb/ interface, so you
still need to use a script to change the file permissions:

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="0471", SYSFS{idProduct}=="0222", \
RUN+="/etc/hotplug/usb/nomadjukebox"

2.6.14 kernels will provide real devices in /dev/bus/usb/, and udev will
be able to directly change their permissions:

SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0471", SYSFS{idProduct}=="0222", \
GROUP="audio"

I do not know what the fuse kernel driver is, but usually drivers
provide a module alias to be matched against the $MODALIAS value
provided by hotplug so they can be automatically loaded.
If they need special handling you can just add a RUN rule (do not forget
to match them on ACTION=="add").
--
ciao,
Marco
Jean-Luc Coulon (f5ibh)
2005-10-12 12:20:16 UTC
Permalink
Hi,

I've an ups (MGE Ellipse) which has an usb connection supported via
nut/nut-usb.

nut-usb uses an hotplug script and usermap:
/etc/hotplug/usb/libhidups
/etc/hotplug/usb/libhid.usermap

Just after udev updrade, it stopped working.

I've reported a bug against nut-usb:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332939

After reading this thread, I've wrote an udev rule:
# udev rules for hid ups
#
BUS!="usb", ACTION!="add", GOTO="libhidups_rules_end"

# MGE Ellipse
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff",
RUN+="/etc/hotplug/usb/libhidups"
# other to be added
#....
LABEL=libhidups_rules_end"


lsusb returns:
[jean-***@tangerine] % lsusb
Bus 005 Device 006: ID 0402:5635 ALi Corp.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 003: ID 0463:ffff MGE UPS Systems UPS
Bus 002 Device 002: ID 046d:c50b Logitech, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 004: ID 046d:08f0 Logitech, Inc.
Bus 001 Device 003: ID 04b8:010a Seiko Epson Corp. Perfection 1640SU
Bus 001 Device 001: ID 0000:0000

ls -l /proc/bus/usb/002/003
-rw-r--r-- 1 root root 52 2005-10-12 14:09 /proc/bus/usb/002/003

The contents of /etc/hotplug/usb/libhidups is:
# This file was installed by the libhid Debian package.
#
# This script changes the permissions and ownership of a USB device
under
# /proc/bus/usb to grant access to this device to users in the nut
group.
#
# Ownership is set to root.nut, permissions are set to 0660.
#
# Arguments :
# -----------
# ACTION=[add|remove]
# DEVICE=/proc/bus/usb/BBB/DDD
# TYPE=usb

if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
chown root:nut "$DEVICE"
chmod 0660 "$DEVICE"
fi

But it seems that my rule is wong as the owner/mode of the ups device
arent modified.

With a previous version I get:
-rw-rw---- 1 root nut 52 2005-10-12 14:13 /proc/bus/usb/002/003

What can be wrong in what I did?
--
Regards

Jean-Luc
Marco d'Itri
2005-10-12 18:10:14 UTC
Permalink
Post by Jean-Luc Coulon (f5ibh)
if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
Remove -a "$TYPE" = "usb", it is wrong and I do not understand how it
can work with hotplug or real hotplug events.
--
ciao,
Marco
Jean-Luc Coulon (f5ibh)
2005-10-12 19:40:19 UTC
Permalink
Post by Marco d'Itri
Post by Jean-Luc Coulon (f5ibh)
if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
Remove -a "$TYPE" = "usb", it is wrong and I do not understand how it
can work with hotplug or real hotplug events.
The rule was applied (permission changed to root:nut) with the previous
version.
I've dropped the $TYPE and got the same result: nothing.
I've use the same "run level" (025_libhidups.rules) int
/etc/udev/rules.d, is it correct?
Post by Marco d'Itri
--
ciao,
Marco
Regards

Jean-Luc
Jean-Luc Coulon (f5ibh)
2005-10-12 20:00:15 UTC
Permalink
Post by Jean-Luc Coulon (f5ibh)
Post by Marco d'Itri
Post by Jean-Luc Coulon (f5ibh)
if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
Remove -a "$TYPE" = "usb", it is wrong and I do not understand how it
can work with hotplug or real hotplug events.
The rule was applied (permission changed to root:nut) with the
previous version.
I've dropped the $TYPE and got the same result: nothing.
I've use the same "run level" (025_libhidups.rules) int
/etc/udev/rules.d, is it correct?
BTW, I've jsut tried the scanner (Epson 1640) managed by
libusb/libsane. I've exactly the same problem, the permissions arent
changed. So it is not useable with a normal user.
Post by Jean-Luc Coulon (f5ibh)
Post by Marco d'Itri
--
ciao,
Marco
Regards
Jean-Luc
Jean-Luc Coulon (f5ibh)
2005-10-16 10:01:23 UTC
Permalink
Post by Jean-Luc Coulon (f5ibh)
Post by Jean-Luc Coulon (f5ibh)
Post by Marco d'Itri
Post by Jean-Luc Coulon (f5ibh)
if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
Remove -a "$TYPE" = "usb", it is wrong and I do not understand how it
can work with hotplug or real hotplug events.
The rule was applied (permission changed to root:nut) with the
previous version.
I've dropped the $TYPE and got the same result: nothing.
I've use the same "run level" (025_libhidups.rules) int
/etc/udev/rules.d, is it correct?
BTW, I've jsut tried the scanner (Epson 1640) managed by
libusb/libsane. I've exactly the same problem, the permissions arent
changed. So it is not useable with a normal user.
At least for sane, it works with 070-5


Jean-Luc

Loading...