[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hardware detection projects

On Sun, 21 May 2000, Wichert Akkerman wrote:

> Previously Dan Shearer wrote:
> > I very much want to see this done in conjunction with the appropriate
> > Debian team.
> I would love to see this happen!

Ok, see the attached. I have sent this to all the people whose code I
looked at, and have had several positive responses back already.


Dan Shearer
phone: +61 8 8369 0303
mob  : +61 411 49 1800
Linuxcare. Support for the Revolution.
Linux Hardware Detection Options for Intel

Version 1.1
Dan Shearer
19 May 2000


	Main Packages
	Small Packages
	Comments on Packages


+ Identify the main open source Intel Linux hardware detection
  packages and their authors.

+ Determine which projects have taken the most general approach, and
  what code there is in common between all projects.

+ Get feedback from as many developers in this area as possible, with
  the aim of encouraging collaboration rather than many overlapping

+ Not be splifficated by upset developers who do not like my opinions
  of their code (... please, submit corrections to me!)


There are two main ways of doing hardware detection: using the kernel
and standalone probing. In all of the following, if only PCI and Plug
and Play cards are to be considered then the hardware detection task
becomes much easier.

   1) kernel detection

   This is firstly done by looking in the strings in the /proc
   directory for hardware that has already been detected, if the
   running kernel happens to be configured for that hardware. It is
   possible to have a matching module in the kernel which doesn't
   detect its hardware due to configuration such as an I/O port, so
   this isn't a blanket solution.  However all of the vital things
   should be present and detectable or the kernel wouldn't be running:
   PCI information, ISA information, the boot drive, etc.

   It is also possible to load and unload all modules present under
   /lib/modules which can be loaded by the running kernel, checking
   their return status and the messages they print. So if the hardware
   on a machine happens to correspond with a module which is compiled
   and present then it will be found. The advantages to this approach
   are that parameters can be supplied to modules, eg: asking the
   module to autoprobe or supplying a base I/O, DMA or IRQ setting.

   2) standalone probing

   Some developers and distributions believe in replicating the probing
   done by the kernel and modules on the theory that guessing which 
   modules to use and how to use them is too likely to give errors.

   Probing the hardware from a standalone program is the only option
   for monitors and video cards, since the kernel doesn't concern
   itself with them at all.

   Each kind of device requires special handling, although there are
   some general algorithms. Often the starting point is the list of
   devices reported by the ISA or PCI bus. For example, a soundcard
   probe can consist of looking for a particular device ID on the PCI
   bus, and in fact the soundcard is never accessed. However a hard
   drive probe also involves reading the first sector on the
   drive. However serial modem detection involves a series of
   capability tests and is not relevant to ISA/PCI bus probes (except
   for finding the serial port in the first place)

Main Packages

detect library 0.9.40 (detect-0.9.40.tar.gz, from Mandrake Cooker)
       Alexandre Dussart <adussart@mandrakesoft.com>
       Bernhard Rosenkraenzer <bero@mandrakesoft.com> 
       Andrew Post <apost@chmi.upmc.edu>
       Stefan Siegel <siegel@informatik.uni-kl.de>
       Philippe Chauvat <philippe.chauvat@sympatico.ca>
       Felipe Rivera Marquez <felipe@informador.com.mx>

Kudzu (kudzu-0.38.tar.gz, from Redhat Rawhide)
       Bill Nottingham <notting@redhat.com>
       Matt Wilson <msw@redhat.com> 
       Erik Troan <ewt@redhat.com>

SuperProbe (part of XFree86, also in the detect library)
       XFree96 team

Corel install/setup procedure
corel-pcimap_1.0-322.tgz from the Corel 1.1 source)
       Corel team (no attribution)

Small Packages

isapnp kernel module (hwprobe.tgz, from ftp.caldera.de)

ddcprobe for monitors (ddcprobe, within RedHat Anaconda installer)
       Nalin Dahyabhai <bigfun@pobox.com>

turbohw (turbohw-0.34, from turbohw-0.34-1.src.rpm)
       Michael Fulbright <msf@redhat.com> (not supported anymore)

turbodetect.c (from TurboLinux 6.0.4 install/misc/src/ directory)
       Unknown <support@turbolinux.com>

xviddetect  (from Debian, not reviewed yet)
       Randolph Chung <tausq@debian.org>

Comments on Packages

Corrections and updates to these comments welcomed.

Debian do not at present do a great deal of hardware detection.

Redhat's Kudzu and Corel Linux keep a database of what hardware is
allegedly in the machine and check this at boot time, taking action if
there is a difference between what is recorded and what is detected.

turbodetect and Corel implement the "loading all kernel modules
present" notion. 

Turbodetect is, in general, pretty horrible code without much idea of

Corel have a very much faster and non-black-screen video detection
scheme, but it isn't as thorough as SuperProbe.

The detect library, Kudzu and Corel have a database of all known PCI
and ISA cards and their ID numbers. These databases aren't all

The Corel source code is in general very neat, but not as thorough as
detect. The kudzu code doesn't have a neatly detached library such as
detect. Kudzu is harddrake and detect in a single package.

It is feasible that detect could be used by pretty well
all the packages examined.

Reply to: