Recently we helped a customer integrate existing OS-independent middleware and device driver software with its own build environment (based on GNU Make) in to VxWorks 7 project build environment. This allowed them to configure and build variants of their software for different target boards and CPU architectures using Wind River Workbench. The integration was achieved using VxWorks 7 subprojects, which are a useful part of the VxWorks 7 layer and package management system.

Components and Layers

The VxWorks real time embedded operating system is built from a series of discrete components and libraries that are combined to create a kernel image that is loaded by a system at start up. These components and libraries are created using a VxWorks Source Build (VSB) project, which are then made available to a VxWorks Image Project (VIP). The VIP uses a board-specific configuration to create a kernel image that runs on one or more target systems.

The VSB and VIP project model is the standard way of building VxWorks images using the Eclipse-based Wind River Workbench development environment and the command-line tools that do the real work of creating and building the projects.

Wind River Workbench can also be used to create projects for application software running on top of the operating system. Projects for software running in the same address spaces as the kernel are known as Downloadable Kernel Module (DKMs) projects. Projects for software running in its own private address space are known Real-time Process (RTP) projects. This works very well for application software that is designed to run on VxWorks and for project teams who use Workbench as their main development system.

VxWorks 7 packaging

VxWorks 7 introduced a new source code packaging system based on the RPM system used by Red Hat Linux distributions. Each OS module is provided as an RPM with strict versioning and dependency definitions, which allows the OS to be easily updated or extended and minimising dependency hell. Each module RPM defines a VxWorks Layer that is turned into a library by a VSB project build.

(VxWorks Layers and Package Management Guide, copyright Wind River Systems 2021.)

Many development teams create software which is built using their own build environment using Make or similar tools. If they want to build their software to run on a VxWorks target system they have a number of options, which are broadly covered by the following:

  • Create one or more VxWorks Layers that build the software to produce libraries that are then linked into the kernel during a VIP build
  • Create one or more Workbench DKM projects that build the software to produce partially-linked object modules that are then linked into the final kernel image during a VIP build
  • Create one or more Workbench RTP projects that build the software to produce fully-linked ELF modules that are loaded and started by the VxWorks kernel at run time.

All the above rely on the application software being organised in a way that is sympathetic to the Workbench project build system. With a large code base this may not be practical or desirable.

VxWorks 7 Subprojects

Fortunately, there is another approach, based on VxWorks Subprojects, which are a part of the VxWorks 7 build system. A VxWorks 7 Subproject has several interesting properties that are useful for including third-party software that has its own set of Makefiles and build rules.

Software included as a VxWorks 7 Subproject:

  • is defined as a VxWorks Layer with meta data that handles dependencies on other packages and layers
  • provides VxWorks Component definitions that allow the software to the be included by a VIP project (like a standard Layer)
  • is copied en masse into the VIP project space so it can include board-specific definitions and configuration files

This has following advantages over the more usual Workbench project types:

  • The software organisation does not have to change
  • The software is built using its own Makefiles by the VIP project build

It’s not all plain sailing though. The VxWorks subproject mechanism is described in the VxWorks Layers and Package Management Guide, including some simple examples, but the use case described here is not covered in much detail.

Work Still Required

The VxWorks Subproject mechanism is not a short cut for building legacy software for VxWorks 7. A developer must still:

  • create a Layer definition for the software
  • ensure the software builds using the VxWorks 7 compiler
  • create Component Definition Files (CDFs) so individual modules can be selected for inclusion in the kernel image
  • create initialisation routines for each module (VxWorks 7 configlettes) that are invoked by kernel during start up

We also found that debugging the Subproject build is quite challenging. The rules in the VxWorks 7 build system that manage the Subproject build are complicated and difficult to follow.

Overall, this was a good solution for the specific software porting problem faced by our client but where possible you should still try to use the standard VxWorks 7 development model.