Why Discover?

(This post was originally an E-mail, sent to explain the reason why discover deserved to be supported in some software. By popular demand [Ian], it is now posted here, slightly edited.)

Discover has three basic design criteria:

  • Arbitrary data. Strictly speaking, discover has no concept of a “Linux kernel module” or “XFree86 driver”. It simply associates data with hardware, and can return that data when the hardware is found. It’s up to add-on utilities to make sense of the data.
  • Versioned data. Version specifications can be attached to data, and can be used to choose between alternatives.
  • Cascading data. That is, newer data can be loaded and override old data.

Thus, it’s easy for us to do things like the following:

  • Pull down data updates from a central source at runtime.
  • Support userspace hardware configuration for utilities such as SANE, CUPS, UPS daemons, CD burn utilities, etc. Adding support for a new utility does not require code changes to discover; often, this can be done with a new data file and a shell script.
  • Support multiple versions and multiple software types. For example, right now we have XFree86 3.x and 4.x driver information in our database, and could easily add X.org and freedesktop.org X server driver info when needed without losing the earlier data. (Or someone else could provide that information and hook it in themselves.)
  • Cross-platform compatibility. We are developing sysdeps that make discover work with FreeBSD, for example. While Linux kernel information wouldn’t likely be useful, userspace configuration would likely be the same everywhere.
  • Driver alternatives. We already do ALSA sound drivers with 2.6 and OSS with 2.4, but we have had several requests to allow ALSA drivers with 2.4 as well. We will support this in our next data release by providing override data that can easily be added to discover’s configuration. You could handle, say, David Hind’s PCMCIA drivers vs. kernel PCMCIA drivers or open-source vs. proprietary NVidia XFree86 drivers the same way.
  • Alternative purpose drivers. We could, for example, specify framebuffer kernel modules and DRI kernel modules for video hardware separately, and load either or both as we see fit.
  • Fine-grained versioning. If a new driver is introduced in Linux 2.6.6, our data can reflect that, so 2.6.5 users aren’t confronted with module load failures.
  • Data annotation. We mark data with dates and IDs currently to show when data was last reviewed (or not, in their absence). We will be adding a “important to debian-installer” tag so that d-i can strip out unnecessary data to save space. We’re also thinking about a rating system that would allow users to vote on, say, whether e100 or eepro100 works better for their particular Intel network card.
  • Packaging. We have already written a spec for associating package data with hardware. So, for example, a utility could offer to install SANE for you if you plug in a scanner, or the installer could notice that you’re installing on a Toshiba laptop and add toshutils. Long-term, we’d like to write a utility that will be able to download kernel module source and build it for the running kernel automatically; this, along with a data update, could allow for field updates of hardware support without requiring new kernels.

Other hardware utilities, such as kudzu or hotplug, suffer from the same deficiency: they are inflexible and difficult to update. As an example, I was recently made aware that the version of kudzu in Debian is too old to support Linux 2.6 kernels; the maintainer is concerned about updating it because of other potential problems he had observed. By contrast, we have made code enhancements to discover recently, some of which make it work better with 2.6, but none of them were required for us to provide good 2.6 support.

None of this is intended to be harsh or confrontational. I don’t think other hardware utilities suck. It may be that discover has fatal defects in its design, and kudzu or hotplug becomes “the way forward” in Linux hardware detection. But we certainly think our ideas about hardware configuration deserve attention, and we’d really like to make them available for others to use.

3 thoughts on “Why Discover?

  1. I would love to find some documents on hardware detection and using discover that will enable me to really use discover for a livecd. Any links, suggestions would be great. There doesn’t seem to be much on the web. Thank you.

Comments are closed.