[cups.bugs] [MOD] STR #4128: libusb-based USB backend: Further fixes

jsmeix.suse jsmeix at suse.de
Thu Jul 12 03:26:35 PDT 2012


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Regarding hard-coded quirk behavior as in usblp kernel module:

Quirks in the kernel must be hard-coded because the kernel
cannot read its quirk behavior from a config file
(e.g. from /boot/vmlinuz-<version>-quirks.conf)
because of security issues (tons of possible security related
stuff would have to be coded in the kernel when it reads files)
and because filesystem access may not yet be possible when the
quirks are needed (think about booting from an USB mass storage
device where quirks for USB are needed to access the USB mass
storage device).

In contrast quirks in application programs (from the kernel's
point of view CUPS' libusb-based USB backend is an application)
do not need to be hard-coded because applications can read
their quirk behavior from a config file (e.g. from
/etc/cups/usb-quirks.conf) or via whatever method that is
appropriate (e.g. DeviceURI options or print queue options)
or even a combination (e.g. system default behavior from
/etc/cups/usb-quirks.conf and queue specific behavior via
DeviceURI and/or print queue options plus hard-coded fallback
behavior).

For debugging of issues that happen on other user's systems
it would help a lot if the libusb-based USB backend provides "DEBUG:..."
or "DEBUG2:..." output for every quirk
(perhaps for log level "debug" this is too much but at least
with log level "debug2" it should become really verbose).

Furthermore for debugging the libusb-based USB backend
it may be useful when its debug messages are sub-prefixed
with a fixed string that identifies the libusb-based USB
backend (e.g. something like "DEBUG: [usb(libusb)backend] ...")
so that it is easy to "grep" them from /var/log/cups/error_log

Link: http://www.cups.org/str.php?L4128
Version: 1.6-current





More information about the cups-devel mailing list