This diagram is an expanded version of the one in the Introduction to FSW Entities tutorial. It adds some entities (Global Symbols, Object Files, and Source Files) which FSW engineers must understand. The following notes discuss these added entities, as well as some related concepts.
Object Files and Constituents
The executable code is contained in "object files", which are produced (i.e., compiled and linked) from corresponding "constituents" (collections of source files). When an embedded system (or a Unix simulation) is loaded, these object files are loaded into RAM by the OS.
Symbols and Interfaces
Each constituent's source code defines a number of symbols (e.g., subroutine entry points, variables), most of which are "visible" only within the current constituent. Some symbols, however, are defined as being part of an "interface". These may be referenced by other constituents, at run time.
To allow run-time flexibility, multiple constituents (and the corresponding object files) may provide a given interface. By specifying which object files should be used in resolving "external" symbols, tasks can gain access to variant implementations of interfaces.
Embedded and Host Systems
VxWorks, like other embedded system environments, requires that all object files be loaded explicitly. Further, the files must be loaded "bottom to top", ensuring that symbols are always resolved. VxWorks makes no distinction between executable and library files; all VxWorks object files have names of the form "lib<con>.o".
On "host" systems (e.g., Linux and Solaris), the full facilities of the operating system are used to load programs. After the top-most (i.e., executable) object file (e.g., "foo") is loaded, the OS resolves any unresolved global symbols from shareable libraries (e.g., "bar.so").
The FSW group has developed a simulation environment which allows (variants of) VxWorks tasks to be run on host systems. The entire set of code is loaded as a single process; POSIX threads play the role of VxWorks tasks.
Tags
Each object file is built for a particular "tag" (e.g., rad750). The tag indicates both the hardware and software environment under which the binary code is expected to run. The rad750 tag, for example, indicates that the code will be run on a radiation-hardened PowerPC 750 CPU under the VxWorks OS.
Tags are used by the build system (e.g., to select the correct compiler options) and by pre-processor macros, embedded in the source code. So, although tags are not "entities", they are definitely important "attributes".
Packages, Constituents, and Interfaces, redux
Each package has a "requirements" file that specifies (among other things) its constituents. Each constituent's interfaces are then defined by a "<con>.cidc" file and some number of "*.cidh" "include" files. Using the C pre-processor, the CMX build system produces "<con>.cido" (constituent definition) and "<con>.cidd" (makefile fragment) files.
For the curious, the above extensions are formed from "cid" (CMX Interface Definition) and some suggestive extensions [cdho] from conventional C usage.