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

From: Thierry Laronde (thierry@cri74.org)
Date: Mon Jul 30 2001 - 04:33:19 EST


[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/


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:43 EST