BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
twenty optional components that could be configured into the VxWorks system
image. By the release of VxWorks 5.4, there were nearly 300, a number that does
not include components offered by third party vendors. Using configuration
header files contributed to development issues in three areas:
Usability. As the system grew in complexity, it became increasingly difficult to
visualize what was in the system. Reading through and modifying lines and lines
of configuration source code became a challenge. Moreover, there was no
mechanism to warn you if the system was misconfigured.
Scalability. Looking at the configuration header files offered no visibility into
dependencies among components. If you do not know what the dependencies are,
you cannot know what is needed nor what can be left out.
New releases. Configuration conflicts among system components occurred when
releasing new product versions, third party components, and customer
modifications because all source code changes occurred in the same two files,
usrConfig.c and configAll.h.
The implementation of the project facility as the configuring tool eliminates the
problems above.
The remainder of this chapter discusses how to work with the Component
Description Language (CDL) and how to release and integrate new components
into the system. Some of the examples in this chapter draw comparisons between
the traditional use of configuration header files and the Tornado 2.x project facility
to illustrate differences between the two schemes, as well as show their
complementarity.
This manual assumes you are already familiar with the functioning of Tornado,
including its project facility. For more information, see the Tornado User’s Guide:
Projects.
NOTE: This release does not restrict you from using the configuration header files
to configure VxWorks and applications. In some circumstances, using config.h and
configAll.h complements the project facility.
112