From: Johannes Meixner <jsmeix@suse.de>
To: linux-hotplug@vger.kernel.org
Subject: external udev rules which list devices
Date: Tue, 01 Mar 2011 14:55:49 +0000 [thread overview]
Message-ID: <alpine.LNX.2.00.1103011450230.22586@nelson.suse.de> (raw)
Hello,
in short:
I ask for an udev enhancement to make support for external
rules easier - in particular as a first step - support
for external listings of device IDs so that generic udev rules
could be applied to those devices.
Reasoning:
Currently udev rules which basically list devices which are
supported by external packages (usually peripheral devices)
so that a generic udev rule is applied to those devices
are in the external software packages which support the devices.
E.g. listings of USB vendor and product IDs for USB scanners
so that an ACL via udev's 70-acl.rules is applied.
Currently the scanner driver package sane-backends provides
its devices list as /etc/udev/rules.d/55-libsane.rules
and the package hplip for HP all-in-one devices provides
its devices list as /etc/udev/rules.d/55-hpmud.rules
In those device list rules the "libsane_matched" variable
is set to "yes" via entries like (long lines wrapped here):
-------------------------------------------------------------------
ACTION!="add", GOTO="libsane_rules_end"
SUBSYSTEMS="scsi", GOTO="libsane_scsi_rules_begin"
SUBSYSTEM="usb", GOTO="libsane_usb_rules_begin"
SUBSYSTEM!="usb", GOTO="libsane_usb_rules_end"
LABEL="libsane_usb_rules_begin"
...
# Epson GT-7700U | Epson Perfection 1240U | Epson Perfection 1240
ATTR{idVendor}="04b8", ATTR{idProduct}="010b", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
# Epson GT-6700U | Epson Perfection 640U | Epson Perfection 640
ATTR{idVendor}="04b8", ATTR{idProduct}="010c", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
...
LABEL="libsane_usb_rules_end"
SUBSYSTEMS!="scsi", GOTO="libsane_scsi_rules_end"
LABEL="libsane_scsi_rules_begin"
...
# Generic: SCSI device type 6 indicates a scanner
KERNEL="sg[0-9]*", ATTR{type}="6", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
# Some scanners advertise themselves as SCSI device type 3
# Epson Perfection 2450 | Epson Perfection 2450 PHOTO
KERNEL="sg[0-9]*", ATTR{type}="3", ATTR{vendor}="EPSON",
ATTR{model}="GT-9700", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
...
LABEL="libsane_scsi_rules_end"
LABEL="libsane_rules_end"
-------------------------------------------------------------------
Unfortunately the syntax of udev rules files and in particular the
values like event value, subsystem value, sysfs attribute values,
and device property values are not meant to be some kind
of "stable interface" so that external software could add
its own rules and rely on that this works "forever".
Regardless that the curent state seems to be pretty stable,
there is no guarantee and it might change in any udev release.
This results a dilemma:
On the one hand:
Because udev rules files are not meant as a "stable interface",
all udev rules files should be part of the udev package.
On the other hand:
If even the udev rules files which basically only list devices
would be part of the udev package, an upgrade of an external
software package to provides support for more external devices
would require an upgrade of udev to get an up-to-date list
of the new supported devices.
Therefore I ask for an udev enhancement to have a stable interface
so that external software packages could provide at least plain
list of devices to udev so that generic udev rules can be applied
to those devices.
There would have to be also a stable interface to specify
which particular generic udev rules should be applied.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
reply other threads:[~2011-03-01 14:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1103011450230.22586@nelson.suse.de \
--to=jsmeix@suse.de \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox