Re: Why so many HW detection packages?
On Fre, 26 Apr 2002, Petter Reinholdtsen wrote:
[...]
> The reson is that there are 3 hardware detection system:
> - Mandrake (libdetect, old)
truly libdetect is old and deprecated
(harddrake (was lothar) used to use it)
we (mandrake) are now mostly using ldetect & ldetect-lst
AFAIK here are the various free software hardware databases:
--------------------------------------------------------------------------------
- pci ----------
- pci.ids (in pciutils)
maps vendor+device -> description
and vendor+device+subvendor+subdevice -> description
also has device classes names
- modules.pcimap (in kernel /lib/modules/2.4*/)
maps vendor+device -> module
and vendor+device+subvendor+subdevice -> module
- XFree's xf86PciInfo.h (in XFree's source: xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h)
maps vendor+device -> description
- RedHat's pcitable (in hwdata)
maps vendor+device -> module+description
and a few vendor+device+subvendor+subdevice -> module+description
when needed
module can also be "Card:xxxx" for XFree (using Cards, see below)
- Mandrake's pcitable (in ldetect-lst)
same format as RedHat's (except for a few syntactical changes since mandrake kept old RedHat's format)
module can also be
"Card:xxxx" for XFree (using Cards+, see below)
"Server:xxxx" for XFree3
"ISDN:xxxx" for hisax special parameters
"Bad:xxxx" for warning about unhandled devices (mainly winmodems)
- Mandrake old detect's pci.lst (in detect-lst)
maps vendor+device -> class+module+description
- Progeny's pci.lst (in discover-data)
same format as detect
maps vendor+device -> class+module+description
module can also be
"Server:XFree86(module)" for XFree4
"Server:XF86_xxx" for XFree3
some comments:
- the "class" in pci.lst is not useful when "module" is given since
from the module name, one can have the "class"
- the subvendor+subdevice distinction is sometimes useful
(not very often though)
- hopefully one day modules.pcimap will be the reference :)
(except for XFree of course)
tools using those databases:
- kudzu and anaconda are using pcitable from hwdata
- library ldetect accesses pcitable from ldetect-lst,
this library is used by DrakX and drakxtools.
Mandrake's patched kudzu uses pcitable from ldetect-lst
- discover uses pci.ids from discover-data
- i don't know if tools are using modules.pcimap
- XFree --------------------
- XFree comes with Cards
- Redhat has its own version (in hwdata)
- Mandrake has its own version Cards+ & CardsNames (in ldetect-lst)
(mainly a merge of XF3 Cards and XF4 Cards)
- discover doesn't need it since it's precising the server name
(XF3) or the module name (XF4) (?)
this is usually enough (except if you want to propose the choice,
but who wants XF3 nowadays :)
- usb --------------------
- usbutils's usb.ids
maps vendor+device -> description
also has device classes names and some more stuff
- modules.usbmap (in kernel /lib/modules/2.4*/)
maps vendor+device -> module (?)
- Mandrake's usbtable (in ldetect-lst)
maps vendor+device -> module+description
module can also be
"Mouse:xxxx" for mouse configuration (fed to mousedrake)
"Tablet:wacom" for wacom tablet configuration
"Flag:xxxx" for DrakX package choosing
"Floppy:normal"
- Progeny's usb.lst (in discover-data)
maps vendor+device -> class+module+description
(but current's version only have module=unknown, so what's it
for, why not usb.ids?)
tools using those databases:
- library ldetect accesses usbtable from ldetect-lst
this library is used by DrakX and drakxtools
- i don't know if tools are using modules.usbmap
- scanner --------------------
- ScannerDB (in ldetect-lst)
maps name -> driver+kind(usb,scsi,serial,parallel)+options+various
(i don't know much about it, i don't know if yves made it from
scratch or what. ask yduret@mandrakesoft.com for more)
- isdn --------------------
- isdn.db (in ldetect-lst)
list of internet providers by country
-> phone number + domainname + dns1 (ip) + dns2
- old or small databases ----------
- isa.lst (detect), isatable (ldetect-lst), modules.isapnpmap (kernel)
- pcmcia.lst (detect, discover-data), pcmciatable (ldetect-lst)
- modules.parportmap (kernel but empty?)
- modules.ieee1394map (kernel but empty?)
--------------------------------------------------------------------------------
There may be some errors, or some missing stuff, please correct me!
I've written a tool to keep in sync with as many databases as
possible. see merge2pcitable.pl in
http://www.mandrakelinux.com/cgi-bin/cvsweb.cgi/soft/ldetect-lst/convert/
Maybe some common mailing list could be set up to deal with this?
*but* note that the database is quite kernel dependent.
- our pcitable doesn't handle this nicely
- redhat has "upgradelist" in hwdata to partly handle this
- i know we handle some pbs via /lib/modutils/macros with things like
"if `kernelversion` = 2.4", debian seems to have it in
/etc/modutils/arch
Once again, hopefully one day modules.pcimap and modules.usbmap will
be the reference! :)
[...]
> Mandrake switched from libdetect to kudzu, afaik
> (latest mandrake (8.2) version is using kudzu for HW detection).
well, mandrake has many tools doing more or less the same thing (and
alas, not exactly always the same thing): DrakX (during install),
drakxtools (when called, after install), kudzu (at boot, usually
calling a drakxtools)
--
Pixel
programming languages addict http://merd.net/pixel/language-study/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: