to a Microkernel POSIX RTOS: A Case Study David Donohoe Senior Software Developer
Introduction Porting Linux applications to a commercial OS can be surprisingly straightforward, provided the OS is based on POSIX, the same industry-standard API used by Linux. Take the QNX Neutrino RTOS, for example. Because it was designed to support POSIX standards, it can run many Linux and open source applications without code changes. In most cases, the developer simply has to recompile and relink the Linux source code. Nonetheless, porting low-level drivers from Linux to QNX Neutrino or to any other OS can be a bit more challenging. For instance, consider the differences between the monolithic kernel used in Linux and the microkernel used in QNX Neutrino. In a monolithic model, device management code resides inside the kernel and, as a result, can't call OS functions in the same way that applications do. Because of this limitation, a Linux driver can't access the facilities of the POSIX API. See Figure 1. Figure 1 In a monolithic OS like Linux, drivers run inside the OS kernel and have no access to the POSIX API. Compare this to a microkernel OS like the QNX Neutrino RTOS, where device drivers run outside the kernel, in separate, memory-protected processes. In this architecture, a device driver is virtually indistinguishable from a regular application: it can be dynamically stopped and started as required, and it can access the same POSIX API that applications use. See Figure 2. 2
Figure 2 In a microkernel OS like QNX Neutrino, drivers run as separate, memory-protected processes and have full access to the POSIX API. Naturally, these differences in kernel architecture must be taken into account when porting drivers. But, as we ll see, they don t necessarily create any special difficulty. In fact, porting drivers from one monolithic OS to another monolithic OS (for example, from Linux to Windows) can be just as hard, or harder. The reason is simple: almost every OS has its own proprietary specification for writing device drivers. As a result, driver code written for one OS typically has to be reworked before it can be plugged in to any other OS, even if the OSs share a similar architecture. Choosing a Driver to Port Exactly how hard or easy is it to port Linux drivers to a microkernel RTOS like QNX Neutrino? Can you reuse most of the original code, or only a little? To provide concrete answers to those questions, we conducted a case study. Because the author had expertise in Ethernet devices, it was decided to port a Linux Ethernet driver. (The intention was to study the effort involved for developers who already have some experience in a given type of device driver.) The driver for the SMC 9452TX Gigabit Ethernet PCI card was chosen because: The source code was available on the SMC Networks website (www.smc.com). The SMC 9452TX card wasn t already supported under the QNX Neutrino RTOS. The source code to the SMC 9452 driver is published under the GPL. Since the case study was merely an academic exercise, the commercial implications of using the GPL were, in this case, not an issue. 3
Porting the SMC 9452TX Linux Driver Source The SMC 9452 driver source is well-structured and well-written, making it a good candidate for porting. Structurally, the driver is divided into two parts: Hardware-specific portion contained approximately 7400 lines of code OS-specific portion contained about 2030 lines of code While Linux and the QNX Neutrino RTOS use different driver interfaces, the interfaces provide similar capabilities. Browsing through the source code, we identified the main interactions between the driver and the rest of the system to determine how much code would need to be modified. The following paragraphs summarize the similarities and differences in the way that Linux and QNX Neutrino handle drivers: Low-level interaction with hardware Both OSs provide straightforward mechanisms that allow a driver to access memorymapped or I/O-mapped device registers. Device detection and configuration Both OSs provide mechanisms to automatically configure devices on the PCI bus, including library calls that let the driver detect the presence of a device and determine the device s configuration. Both OSs also provide mechanisms that let the user supply configuration parameters that affect the driver s operation. These parameters are implemented quite differently under the two OSs, however. Under QNX Neutrino, device driver options are parsed, and the configuration information is stored in private, per-device data structures. Under Linux, this information is stored in global variables within the driver module. Interrupt handling Both OSs allow a thread to execute the driver s interrupt-handling code in response to interrupt-generating events that are triggered by the device. Network traffic: sending and receiving packets The format of packet data buffers and the API for transferring data between the device driver and the OS s networking infrastructure are different, but the principles are the same. Miscellaneous functionality This includes functionality such as multicast address filtering and statistics gathering. Again, while the APIs for providing the functionality differ, the principles are the same. 4
Hardware-specific Code The hardware-specific code all 7400 lines of it didn t need to be modified. It was simply standard ANSI C code that communicates with the SMC 9452 card via a handful of macros from a header file. These macros were reimplemented for QNX Neutrino in the header file as follows: #define NsmRegRead8(ctx, addr, pval) #define NsmRegRead16(ctx, addr, pval) #define NsmRegRead32(ctx, addr, pval) *(pval) = (*(volatile uint8_t *)(addr)) *(pval) = (*(volatile uint16_t *)(addr)) *(pval) = (*(volatile uint32_t *)(addr)) #define NsmRegWrite8(ctx, addr, val) #define NsmRegWrite16(ctx, addr, val) #define NsmRegWrite32(ctx, addr, val) *(volatile uint8_t *)(addr) = (val) *(volatile uint16_t *)(addr) = (val) *(volatile uint32_t *)(addr) = (val) Since the hardware-specific code is passed a pointer to the device s memory-mapped registers, these macros were all we needed to communicate with the SMC 9452 hardware. OS-specific Code Next came the OS-specific code. While we were able to maintain the overall structure of this code, significant portions had to be implemented or re-implemented. For instance, we needed to implement command-line option-string parsing, which is a unique capability of QNX drivers. Conveniently, code that handles this parsing already exists: We simply lifted the code from the network driver development kit (DDK) for the QNX Neutrino RTOS. (Note that QNX Neutrino supports many drivers for PCI network cards, including the pcnet driver supplied with this DDK.) We were also able to reuse a lot of code from a QNX Neutrino driver written for a different PCI network card, which greatly reduced development time. In the end, the new driver for the SMC 9452 card had about 1600 lines of OS-specific code, compared to the 2030 lines of OSspecific code in the original Linux driver. Overall, about 80 percent of the code from existing Linux driver was preserved. Results After about 10 hours of development, the new code provided the basic capabilities expected of an Ethernet driver: packet transmission and reception statistics gathering multicast address filtering 5
The new driver also followed the normal QNX Neutrino driver conventions for option parsing, link detection, and so on. Performance Testing Next, we measured the performance of the resulting driver, using the TCP netperf throughput measuring utility. (Since this was a case-study exercise only, we didn t attempt to optimize the driver performance.) The machines used for measuring throughput were configured as follows: A 2GHz Pentium IV machine with an Intel 82544 Gigabit card. A 450Mhz Pentium III machine with an SMC 9452TX Gigabit card. Netperf test: Intel 82544 to SMC 9452 Recv socket Send socket Send message Elapsed time (secs) Throughput (kbytes/sec) 16384 22528 22528 10.00 28706.91 Netperf test: SMC 9452 to Intel 82544 Recv socket Send socket Send message Elapsed time (secs) Throughput (kbytes/sec) 16384 22528 22528 10.00 20661.70 Note All results are for a non-optimized driver. Faster Driver Development through User-Space Debugging An existing code base of driver software for one OS can help accelerate migration to a different OS, even if the two OSs have fundamental differences in architecture. In this case, we reused about 80 percent of the original driver code, allowing an initial driver port to be completed very quickly. Nonetheless, the fast development time can be partially attributed to the microkernel architecture of the QNX Neutrino RTOS, which allows drivers to run as memory-protected processes in user space. During development, several mistakes caused the driver code to crash. Nevertheless, we never had to reboot the system. We simply fixed the offending sections of code and restarted the networking subsystem with the updated driver. If you have 6
ever developed drivers for a monolithic kernel, where a driver bug will crash the entire OS, you ll immediately appreciate the benefits of this rapid driver recovery. Naturally, the more a developer knows about the technologies related to the drivers that he or she is porting, the better equipped they will be for the task. For instance, anyone qualified to write an Ethernet driver for a multitasking, memory-protected OS should be able to complete a driver port in a relatively short timeframe. Of course, familiarity with the target OS will help the developer complete the job more quickly. In the case of the QNX Neutrino RTOS, a background in POSIX application development will also be beneficial, since the QNX device drivers have full access to the POSIX API. 7
About, a Harman International company, is the industry leader in realtime embedded OS technology. The component-based architectures of the QNX Neutrino RTOS and QNX Momentics development suite together provide the industry s most reliable and scalable framework for building innovative, high-performance embedded systems. Global leaders such as Cisco, DaimlerChrysler, General Electric, Lockheed Martin, and Siemens depend on QNX technology for network routers, medical instruments, vehicle telematics units, security and defense systems, industrial robotics, and other mission- or life-critical applications. Founded in 1980, is headquartered in Ottawa, Canada, and distributes products in over 100 countries worldwide. www.qnx.com 2005 GmbH & Co. KG. All rights reserved. Published with permission of International Corporation. QNX, Momentics, and Neutrino are trademarks of GmbH & Co. KG, registered in certain jurisdictions, and are used under license. All other trademarks and trade names belong to their respective owners.