About the Specification Database
The total number of interfaces and other bits of information that are needed to completely describe the ABI for Linux is vast, on the order of several tens of thousands of pieces of data. Other ABI efforts have maintained this information manually (that is, via edits to the document). This seemed like a very inefficient process, especially considering the rate at which Linux is changing.
A database provides a structured way to manage this data, and allows portions of the document to be created from the database, thus avoiding a lot of tedious, error-prone editing.
An additional benefit of having the ABI represented in a database is that certain parts of the test suite can also be generated from the data. The application checker, appchk, which performs a static analysis of an application, contains serveral tables, each of which is pulled from the database. Similarly libchk, the runtime library checker, gets all the information on libraries and interfaces from the database. The development environment checker, devchk, which is used to check the header files is almost entirely pulled from the database.
Enough information is held in the database, that a set of clean "reference" headers can be created.
Note: some of this documentation is incomplete and/or dated
These are mostly perl scripts available over several modules under the LSB project sources which interact with the DB in one way or another.
- mk* specification scripts - available in the lsbspec bzr branch
- LibtoDB - available in the scripts bzr branch
- DevChk - available in the misc-test bzr branch
- dynchk - dynamic application checker
- mkheader - in the build_env branch
- mktags - Packaging script
Issues With Current Spec Database
- There is some obsolete data, as well as inconsistent data and uses of data. For example, Array sizes are used differently in different places.
- There is no understanding of gcc extensions, although it's not clear yet if these are needed. There's a hack to deal with the __attribute(__aligned__(xx)) construct. If something else comes up as required, we might need to make a more general solution. Note: C++ has __attribute__((__noreturn__)) which is not in the database now.
- Scripts which work with the DB data are not consistent - there's a lot of reduncancy in the code to extract the data, and they don't always handle output the same way. It would be better to have a library (perl module if the scripts continue to be perl) to do the common bits, and have the individual scripts just be output routines.
- The rudimentary support for modules (e.g. C++, Graphics, Core) is incomplete. This needs adding to the Interface and Command tables, and several others. It should be possible for the scripts to selectively include and exclude modules, e.g. "generate stub libraries excluding the desktop module", etc.
- Don't know how to generate C++ headers from the DB.
- The DB doesn't know how to describe C++ class structures - we don't have class data and class functions. We also don't have inheritance data sufficient to instruct libchk to carry out the testing strategy propsed in bug 1063, comment #4
- Need a tool to automate the process of creating arch-specific interface data. This process seems like it would be the simplest:
- Create a single All entry, run the tool which turns this into seven arch-specific entries and removes the All entry Now we fill in the individual arch-specific entries.This would match well with an automated capture tool, which on its first pass would not know that information is arch-specific, and would just create the All entry.
- Alternate approach for creating arch-specific entries in ArchType and ArchTypeMem is to create an ArchType entery for one architecture (libtodb tool does that) and then run devchk on different architecture (That will create entry for different architecture). Then write a tool which will purge the enteries and replace with one entry for All architecture if size and offset is same on all architecture.