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.
Regards,
--
Dan Shearer
dan@linuxcare.com
phone: +61 8 8369 0303
mob : +61 411 49 1800
http://linuxcare.com
Linuxcare. Support for the Revolution.
Linux Hardware Detection Options for Intel
==========================================
Version 1.1
Dan Shearer
dan@linuxcare.com
19 May 2000
Contents
--------
Goals
Techniques
Main Packages
Small Packages
Comments on Packages
Goals
-----
+ 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
projects.
+ Not be splifficated by upset developers who do not like my opinions
of their code (... please, submit corrections to me!)
Techniques
----------
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-detect-util_1.0-322.tgz,
corel-isa-detect_1.0-322.tgz,
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)
duwe@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
modularisation.
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
identical.
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: