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

[PCI] building PCI IDs/drivers DB from Linux kernel sources



[I'm sorry for crossposting, but since it could be of some interest for
Debian installation AND involves the linux sources...]

Please note that in the following, these are remarks _not_ bad criticism.
Maybe what is found by the script could be of some interest to people
coordinating the source writing.

GOAL
----

In order to allow a kind of light detection of hardware to be use during
installation, I wanted to build a database (for PCI: I start with the
easiest...) with the following format:

CLASS_ID	VENDOR_ID	DEVICE_ID	driver_name

I have decided to write a script (you will find all the stuff attached)
parsing the Linux kernel sources in order to do that.

RULES
-----

The strategy adopted is to try to find rules that apply to a great number of
files, if not all, and to treat the least possible exceptions by hand.

For retrieving the information I found 2 main rules.

R1: mainly for the net drivers, since one person is at the origin (Donald
Becker), I scan the files in order to discover pci_tbl arrays of
pci_device_id, and retrieve info from here.
	Since some files have the magic numbers hardcoded, and others use
	constant names, the files are preprocessed.
	When the preprocess fails (config.h is created, asm symlink too), I
	suspect that the driver is not buildable for the ARCH

R2: for the others, since the devices ids are spread all around, I search
for PCI_DEVICE_ID_* strings, extract them from the sources, construct
PCI_VENDOR_ID and put the driver name, and finally try to preprocess the
database, against pci_ids.h and others macro definitions found in the
sources.

PROBLEMS
--------

Macro definitions:

I have found two macros not defined anywhere (sorry, this is for 2.4.6; I
haven't try for later):

PCI_DEVICE_ID_PHILIPS_SAA9730
PCI_DEVICE_ID_V3_SEMI_V370PDC

Driver names:

I try to match the filename processed (minus the suffix) against entries in
the Makefile, and even try a substring against the Makefile in order to
guess the correct driver name. When everything fails, the log file indicates
the problem, and I have built a "drivers_aliases" giving the correct name
for these files.

Class ids:

This is one of the main problem. For some drivers, the directory tree allows
an easy matching. For example for 'net', the drivers at the root are
ethernet, tokenring is in a subdirectory, etc...
For others, for example in 'char' one must almost try to put the match by
hand [this is not a surprise since in Unix like kernels char is a default].

Completeness:

At the moment, the DB (you will find it in the tarball attached) is an
almost 600 entries one. But I have only treated the "regular" (rules 1 or 2)
files and there remains 30% of exceptions.

SOLUTIONS ?
-----------

To be able to construct almost automagically the DB could be of some
interest, since pci_ids is not exhaustive, and definitions are spread all
around.
May I suggest some possible tracks?

* Use of macro definitions for magic numbers

Could the policy be to not hardcode the magic numbers but only to use
preprocessing and put PCI_DEVICE_* etc in place of the hexa values? This
could allow to use only rule 2.

* Define the driver name in the file

The driver name is not always easy to automatically guess. Could the policy
be that the driver name is defined in the source via a macro ?

* Define the class name in the file too

Trying to organize sources following the PCI classes distinction will not be
always a good idea. IMHO, the simple way would be to define too in the
drivers source a macro defining the class.

The class id is important for example to sort the DB. If one has to
construct an installer and has a limited place (general case for initrd),
one could want to extract only all the records for net devices from the DB,
or only SCSI controlers and so on...


Thank for reading,

Note: The DB constructed is _not_ garanty to be bullet proof. For example,
since this is only alpha tests, the class id are probably wrong for some
devices. Comments absolutely welcomed.
-- 
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org/

Attachment: dmodtools.tgz
Description: GNU Unix tar archive


Reply to: