Re: Hardware detection projects
How is going this project?
I want to help. Is there a mailing-list? Some alpha-code to play?
Quoting Dan Shearer (dan@linuxcare.com):
> 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: