Recently, we successfully assisted a client in integrating their pre-existing, operating system-agnostic middleware and device driver software into a VxWorks 7 project build environment. This integration allowed them to configure and generate various software versions tailored to different target boards and CPU architectures within Wind River Workbench, utilizing their established GNU Make-based build system. We leveraged VxWorks 7 subprojects, a valuable feature of the VxWorks 7 layer and package management system, to achieve this.
Understanding VxWorks 7’s Structure: Components and Layers
The VxWorks real-time embedded operating system is constructed from distinct components and libraries. These elements are combined to form a kernel image, which the system loads during startup. A VxWorks Source Build (VSB) project is used to create these components and libraries, making them accessible to a VxWorks Image Project (VIP). The VIP, using board-specific configurations, generates a kernel image suitable for one or more target systems.
The VSB and VIP project model represents the standard method for building VxWorks images using the Eclipse-based Wind River Workbench development environment and its command-line tools. Workbench also facilitates the creation of application software projects that run on top of the operating system. Projects for software operating within the kernel’s address space are known as Downloadable Kernel Modules (DKMs), while those running in their own isolated address spaces are Real-time Process (RTP) projects. This setup is ideal for applications designed specifically for VxWorks and for development teams who rely on Workbench as their primary development platform.
VxWorks 7’s Packaging System
VxWorks 7 introduced a new source code packaging system, drawing inspiration from the RPM system used in Red Hat Linux distributions. Each OS module is packaged as an RPM with stringent versioning and dependency definitions, enabling effortless OS updates and extensions while minimizing dependency conflicts. Each module RPM defines a VxWorks Layer, which is transformed into a library by a VSB project build.
(VxWorks Layers and Package Management Guide, copyright Wind River Systems 2021.)
Many development teams utilize their own build environments with Make or similar tools. When integrating their software with a VxWorks target system, they typically consider these options:
- Constructing one or more VxWorks Layers to build the software into libraries, which are then linked into the kernel during a VIP build.
- Developing one or more Workbench DKM projects to produce partially-linked object modules, subsequently linked into the final kernel image during a VIP build.
- Creating one or more Workbench RTP projects to generate fully-linked ELF modules, which the VxWorks kernel loads and initiates at runtime.
These options necessitate that the application software be structured in a manner compatible with the Workbench project build system, which may be impractical or undesirable for large codebases.
The Advantage of VxWorks 7 Subprojects
Fortunately, VxWorks 7 Subprojects offer an alternative approach. These subprojects, integral to the VxWorks 7 build system, possess properties that are particularly useful for incorporating third-party software with its own Makefiles and build rules.
Software integrated as a VxWorks 7 Subproject:
- Is defined as a VxWorks Layer, complete with metadata for managing dependencies on other packages and layers.
- Provides VxWorks Component definitions, enabling the software’s inclusion in a VIP project, similar to a standard Layer.
- Is copied in its entirety into the VIP project space, allowing for the inclusion of board-specific definitions and configuration files.
This method offers advantages over standard Workbench project types:
- The existing software organization remains unchanged.
- The software is built using its native Makefiles within the VIP project build.
However, challenges exist. While the VxWorks Layers and Package Management Guide provides an overview and basic examples of the subproject mechanism, it lacks detailed coverage of the use case described here.
Essential Development Tasks
The VxWorks Subproject mechanism is not a simple solution for porting legacy software to VxWorks 7. Developers must still:
- Create a Layer definition for the software.
- Ensure the software compiles using the VxWorks 7 compiler.
- Develop Component Definition Files (CDFs) to enable the selection of individual modules for inclusion in the kernel image.
- Create initialisation routines for each module (VxWorks 7 configlettes) that are invoked by kernel during startup. Furthermore, debugging the Subproject build can be challenging due to the complexity of the VxWorks 7 build system’s rules.
In conclusion, while this approach proved effective for our client’s specific software porting needs, the standard VxWorks 7 development model remains the preferred method whenever feasible.