Yesterday, I wrote about the +modalias +values provided by the Linux kernel following my hope for +better +dongle support in Debian. Using this knowledge, I have tested how +modalias values attached to package names can be used to map packages +to hardware. This allow the system to look up and suggest relevant +packages when I plug in some new hardware into my machine, and replace +discover and discover-data as the database used to map hardware to +packages.
+ +I create a modaliases file with entries like the following, +containing package name, kernel module name (if relevant, otherwise +the package name) and globs matching the relevant hardware +modalias.
+ ++Package: package-name ++ +
Modaliases: module(modaliasglob, modaliasglob, modaliasglob) +
It is fairly trivial to write code to find the relevant packages +for a given modalias value using this file.
+ +An entry like this would suggest the video and picture application +cheese for many USB web cameras (interface bus class 0E01):
+ ++Package: cheese ++ +
Modaliases: cheese(usb:v*p*d*dc*dsc*dp*ic0Eisc01ip*) +
An entry like this would suggest the pcmciautils package when a +CardBus bridge (bus class 0607) PCI device is present:
+ ++Package: pcmciautils ++ +
Modaliases: pcmciautils(pci:v*d*sv*sd*bc06sc07i*) +
An entry like this would suggest the package colorhug-client when +plugging in a ColorHug with USB IDs 04D8:F8DA:
+ ++Package: colorhug-client ++ +
Modaliases: colorhug-client(usb:v04D8pF8DAd*) +
I believe the format is compatible with the format of the Packages +file in the Debian archive. Ubuntu already uses their Packages file +to store their mappings from packages to hardware.
+ +By adding a XB-Modaliases: header in debian/control, any .deb can +announce the hardware it support in a way my prototype understand. +This allow those publishing packages in an APT source outside the +Debian archive as well as those backporting packages to make sure the +hardware mapping are included in the package meta information. I've +tested such header in the pymissile package, and its modalias mapping +is working as it should with my prototype. It even made it to Ubuntu +Raring.
+ +To test if it was possible to look up supported hardware using only +the shell tools available in the Debian installer, I wrote a shell +implementation of the lookup code. The idea is to create files for +each modalias and let the shell do the matching. Please check out and +try the +hw-support-lookup +shell script. It run without any extra dependencies and fetch the +hardware mappings from the Debian archive and the subversion +repository where I currently work on my prototype.
+ +When I use it on a machine with a yubikey inserted, it suggest to +install yubikey-personalization:
+ ++% ./hw-support-lookup ++ +
yubikey-personalization +
% +
When I run it on my Thinkpad X40 with a PCMCIA/CardBus slot, it +propose to install the pcmciautils package:
+ ++% ./hw-support-lookup ++ +
pcmciautils +
% +
If you know of any hardware-package mapping that should be added to +my +database, please tell me about it.
+ +It could be possible to generate several of the mappings between +packages and hardware. One source would be to look at packages with +kernel modules, ie packages with *.ko files in /lib/modules/, and +extract their modalias information. Another would be to look at +packages with udev rules, ie packages with files in +/lib/udev/rules.d/, and extract their vendor/model information to +generate a modalias matching rule. I have not tested any of these to +see if it work.
+ +If you want to help implementing a system to let us propose what +packages to install when new hardware is plugged into a Debian +machine, please send me an email or talk to me on +#debian-devel.
+ +