Many developers have misconceptions regarding migrating from VxWorks to Linux. Here are answers to five common questions.

Q: Is Linux networking up to the task?

A: Many VxWorks developers come to Linux with two sorts of concerns about Linux networking:

1. The first is suitability. Many OEMs find the TCP/IP stack included with VxWorks to be buggy and unreliable. Furthermore, since VxWorks is a proprietary, closed source OS, they can not readily improve it and so have to replace it wholesale. Unlike the VxWorks BSD-based networking stack, Linux TCP/IP is completely open source: You can review the code, make changes, and submit patches back to community repositories. Moreover, the Linux TCP/IP stack powers tens of millions of Linux-based web servers and ubiquitous routers, switches, and Internet appliances. The correctness of this choice made by both IT managers and OEMs is further supported by independent source code quality studies by companies like Coverity and Reasoning.
   
   
2. The second area of concern is performance. Wind River and other legacy vendors have published synthetic benchmarks (usually with netbench), predictably showing Linux networking as deficient when compared to VxWorks and other legacy platforms. These benchmarks invariably involve arbitrarily small packet sizes (≤16 bytes) atypical of real-world applications. For packet sizes of 32 bytes and larger, Linux shows clearly higher throughput and continues to make gains as packet size increases. This performance advantage comes from better marshalling algorithms and more robust memory management, bolstered by a global community development model.
   

Q: Can performance-sensitive code reside in user space?

A: With VxWorks, no distinction exists between system code and user code. All execution occurs in privileged mode. Device drivers, interrupt handlers, time critical operations, and mainstream application code all run as if they were part of the kernel (albeit with different priorities). By contrast, Linux leverages native CPU mechanisms for segregating code into system-critical operation (kernel space) and user applications (user space). But Linux also employs a design philosophy of minimizing critical, kernel-level code and of avoiding system calls altogether whenever possible (e.g., implementing systems functions in user space libraries).

When migrating your embedded applications to Linux, many developers find themselves tempted to insert all critical code into kernel space. Certainly, Linux architecture predicates that the "top half" of device drivers do reside in kernel space. But the business end of drivers, as well as other I/O-related and real-time code, need not migrate to kernel space as well. The privileges accorded to kernel space execution lie in the domain of security and access to kernel data, not in performance and throughput. Indeed, your project will be better served by migrating such code to user space where it can be prioritized and tuned appropriately, not into the kernel. In kernel space, application-specific code can compete with mundane but critical kernel oeprations; it will lack access to standard libraries like glibc; it will bloat your system's trusted computing base (TCB); and it can potentially destabilize system-wide performance.

Q: What happens to process resources at exit?

A: In VxWorks, all running tasks allocate dynamic resources from a shared pool using APIs derived from and working similarly to the C library malloc() function. When a VxWorks task hangs or terminates abnormally, it is practically impossible to recover dynamic allocations – cooperative memory allocation leads to system-wide memory leaks and eventually the need to reboot.

As with VxWorks, Linux processes (and threads within them) can dynamically allocate resources as needed in the course of execution. However, upon termination, graceful or otherwise, the Linux run-time is able to recover those resources – even resources shared with other processes. (Resources shared across processes are freed when the last sharing program terminates or frees them explicitly. For more on this, investigate robust mutexes at http://devresources.linux-foundation.org/dev/robustmutexes/ and elsewhere.)

Q: Why does Linux require a file system?

A: Legacy VxWorks systems initialize by loading a single image from ROM to RAM. That image contains the VxWorks kernel, libraries, drivers, applications and any other code and often data of interest. In this context, the notion of a file system entails additional software to access external storage media.

By contrast Linux requires the presence of a file system to operate. The main reason behind this requirement is that programs in Linux, starting at boot-time with init, are invoked by supplying a file descriptor/pathname for retrieving a program image. (At the process level. Threads within processes are launched comparably to VxWorks tasks, with pthread_create().) The Linux loader and APIs like execv() follow this paradigm, regardless of whether the program in question is a binary executable, a script or other program entity.

Linux does not require, however, the presence of rotating media, i.e., disks. Embedded designs and even desktop and server distributions can operate from file systems implemented in RAM, flash, over a network, and/or with disks implemented as solid-state devices or on media with spindles and platters. Tens of thousands of Linux-based applications are deployed this way, with no impact on footprint or performance.

Q: Must OEM product updates be delivered in source?

A: With VxWorks, updates, upgrades and patches usually require a complete rebuild of the image containing the VxWorks kernel, libraries, drivers, application code and data. OEMs, their channel, and their customers must acquire a complete new software load, or portions thereof in source code, and build and reconstitute a system image. The target system must be shut down and a BIOS or other firmware then mediates local or remote reflashing of the main system ROM, followed by a reboot.

As noted in the previous section, all Linux systems deploy with some type of file system. While this requirement may seem burdensome (it is not), it also facilitates field updates and upgrades in either source or binary. Without interrupting operating applications, Linux-based devices can receive new versions of applications, libraries, drivers or other critical code and store them in the local file system (e.g., in flash). Individual applications can then restart with newly loaded program code without need for rebooting or other interruption. Patched libraries will be ready the next time user programs load or access them. And, modified device drivers can be stopped, unloaded and reloaded, in most cases without need for rebooting.