0806 02 Los5 - Ug

3
LynxOS User’s Guide

LynxOS Release 5.0
DOC-0806-02
Product names mentioned in LynxOS User’s Guide are trademarks of their respective manufacturers and are used here
for identification purposes only.
Copyright ©1987 - 2010, LynuxWorks, Inc. All rights reserved.

U.S. Patents 5,469,571; 5,594,903; 6,075,939; 7,047,521
Printed in the United States of America.
All rights reserved. No part of LynxOS User’s Guide may be reproduced, stored in a retrieval system, or transmitted, in
any form or by any means, electronic, mechanical, photographic, magnetic, or otherwise, without the prior written
permission of LynuxWorks, Inc.
LynuxWorks, Inc. makes no representations, express or implied, with respect to this documentation or the software it
describes, including (with no limitation) any implied warranties of utility or fitness for any particular purpose; all such
warranties are expressly disclaimed. Neither LynuxWorks, Inc., nor its distributors, nor its dealers shall be liable for any
indirect, incidental, or consequential damages under any circumstances.
(The exclusion of implied warranties may not apply in all cases under some statutes, and thus the above exclusion may
not apply. This warranty provides the purchaser with specific legal rights. There may be other purchaser rights which
vary from state to state within the United States of America.)
Contents
PREFACE ............................................................................................................... IX
For More Information ..................................................................................... ix
Typographical Conventions ............................................................................. x
Special Notes .................................................................................................. xi
Technical Support .......................................................................................... xii
How to Submit a Support Request ......................................................... xii
Where to Submit a Support Request .....................................................xiii
CHAPTER 1 OVERVIEW ................................................................................................ 1
CHAPTER 2 UNDERSTANDING LYNXOS........................................................................ 3

What LynxOS Is .............................................................................................. 3
LynxOS Environment ...................................................................................... 3
What LynxOS Offers ....................................................................................... 4
Advantages of LynxOS ............................................................................ 4
New Features ............................................................................................ 4
CHAPTER 3 LYNXOS ARCHITECTURE ........................................................................... 7

LynxOS Operating System .............................................................................. 7
System Services ........................................................................................ 8
Kernel ....................................................................................................... 9
Boot Code ................................................................................................. 9
CSP ........................................................................................................... 9
BSP and DRM .......................................................................................... 9
Static Device Drivers .............................................................................. 10
Static Device Info Files .......................................................................... 10
Dynamic Device Drivers ........................................................................ 10
LynxOS User’s Guide iii

Contents
Dynamic Device Info Files .................................................................... 10
CHAPTER 4 SYMMETRIC MULTIPROCESSING (SMP) ................................................... 11

Scheduling ..................................................................................................... 11
Scheduling in General Purpose OS'es .................................................... 11
Scheduling in LynxOS ........................................................................... 12
SMP User-Level Impact ................................................................................ 13
Custom Applications .............................................................................. 13
The Number of CPUs in the System ...................................................... 14
Utilities ................................................................................................... 14
CHAPTER 5 SUPPORT FOR POSIX.13 PSE53 SYSTEM PROFILE IN LYNXOS................ 15

What is POSIX.13? ....................................................................................... 15
An Overview of the POSIX.1 Standard ........................................................ 15
The POSIX.13 System Profiles ..................................................................... 16
The POSIX.1 Options .................................................................................... 17
The Units of Functionality in POSIX.13 ....................................................... 18
Implementation-Defined Functionality .................................................. 19
The POSIX.26 Standard ................................................................................ 20
Limitations of PSE53 Support in LynxOS .................................................... 21
The POSIX System Parameters ..................................................................... 21
Runtime Invariant Values .............................................................................. 21
Partial PSE54 Support in LynxOS ................................................................ 23
CHAPTER 6 SHARED LIBRARIES .................................................................................. 25

Overview ....................................................................................................... 25
Creating Shared Libraries by Default ..................................................... 26
Single/Multithreaded Applications and Shared Libraries ...................... 26
Lazy Linking .......................................................................................... 26
Effects of Using Shared Libraries ................................................................. 27
System Memory Usage .......................................................................... 27
Disk Space Usage ................................................................................... 28
Code Maintenance .................................................................................. 28
Determining the Use of Shared Libraries ...................................................... 29
Example 1 ............................................................................................... 30
Example 2 ............................................................................................... 31
Example 3 ............................................................................................... 33
iv LynxOS User’s Guide

Choosing Shared Library Contents ........................................................ 35
Updating Shared Libraries ...................................................................... 35
Libraries Provided ......................................................................................... 36
Creating Shared Libraries ....................................................................... 37
Linking to a Shared Library ................................................................... 37
CHAPTER 7 CUSTOMIZING THE DEFAULT

LYNXOS KERNEL CONFIGURATION39
Reasons for Kernel Customization ................................................................ 39
Customizing for Performance ................................................................ 39
Customizing for Size .............................................................................. 40
Customizing for Functionality ................................................................ 40
Overview of the /sys Directory ...................................................................... 41
Accessing and Modifying the Main Kernel Directory ........................... 43
Customizing from a Cross-Development Host .............................................. 46
Adding TCP/IP to a LynxOS Kernel ...................................................... 46
Customizing a Kernel for Performance ......................................................... 47
Configurable Parameters in /sys/bsp.<bsp_name>/uparam.h ................ 47
Parameter Default Values in /sys/bsp.<bsp_name>/uparam.h ............... 48
Increasing Maximum Processes ............................................................. 49
Customizing the Number of CPUs ................................................................ 50
Changing Kernel Size .................................................................................... 52
Determining the Kernel Size .................................................................. 52
Reducing the Number of TCP/IP Buffers .............................................. 54
Removing Unused Device Drivers ......................................................... 55
Adding Functionality to a Kernel .................................................................. 56
Adding a Custom Device Driver ............................................................ 56
Configurable Tick Timer ............................................................................... 58
CHAPTER 8 CREATING KERNEL DOWNLOADABLE IMAGES ........................................... 59

Overview ....................................................................................................... 59
mkimage—the LynxOS KDI Creation Utility ............................................... 59
mkimage Syntax and Features ................................................................ 60
LynxOS Kernel .............................................................................................. 60
Embedded File Systems ................................................................................. 61
Embedded Root File Systems ................................................................. 61
Embedded Standalone File System Images ............................................ 61
LynxOS User’s Guide v

Contents
Resident Text Segments ................................................................................ 62

Creating a KDI Image ................................................................................... 63
Procedure Overview ............................................................................... 63
Enabling the RAM Disk Driver ............................................................. 64
Modifying Kernel Parameters ................................................................ 64
Creating a Specification File .................................................................. 64
Testing Kernel Images ........................................................................... 66
Booting KDIs ................................................................................................. 66
Booting Images over a Network ............................................................. 66
Sample KDIs ................................................................................................. 67
KDI Build Templates .................................................................................... 67
Template Conceptual Overview ............................................................. 68
Included KDI Build Templates .............................................................. 68
KDI Directory Structure ......................................................................... 69
Restrictions ............................................................................................. 70
Getting Started ........................................................................................ 70
Building KDIs ........................................................................................ 71
Example—Building, Booting, and Using the developer KDI ....................... 72
Configuring the developer KDI .............................................................. 73
CHAPTER 9 LINUX ABI COMPATIBILITY ...................................................................... 75

Overview ....................................................................................................... 75
Linux ABI Layer ........................................................................................... 76
Interoperability with LynxOS Native Applications ............................... 77
Linux ABI Shared Libraries ................................................................... 77
Adding Linux Shared Libraries to LynxOS .................................................. 79
Linux ABI Shared Libraries Not To Be Overwritten ............................. 80
Specifying Linux ABI Shared Library Paths ................................................. 81
Additional Features and Functions of Linux ABI ......................................... 82
Linux Reference Distribution ................................................................. 82
Support for Dynamically Linked Applications ...................................... 82
/proc File System Support ...................................................................... 83
Exceptions and Limitations .................................................................... 85
Extracting RPMs with rpm2cpio ............................................................ 86
Running Applications on Linux ABI ............................................................ 86
Example—Linux ABI Usage ........................................................................ 89
vi LynxOS User’s Guide

CHAPTER 10 XFREE86 AND LESSTIF............................................................................ 91
Components Overview and Source Baseline ................................................. 92
Libraries Linkage ........................................................................................... 93
Utilities Linkage ............................................................................................ 93
Multithreads Support ..................................................................................... 94
Supported LynxOS 5.0 BSPs ......................................................................... 94
Supported LynxOS 5.0 Cross-Development Hosts ....................................... 94
Supported Hardware ...................................................................................... 95
Supported Targets ................................................................................... 95
Graphics Adapter Support ...................................................................... 95
Mouse Support ....................................................................................... 95
Keyboard Support ................................................................................... 96
Monitor Support ..................................................................................... 96
Using the i810_drv.o and i810_xorg_7.2.0_drv.o X Server Video Drivers .. 96
X Server Configuration ................................................................................. 97
Setting Color Depth and Monitor Resolution ......................................... 97
XFree86 Demo System .................................................................................. 98
XFree86 Demo System Overview .......................................................... 98
Configuring XFree86 Demo System ...................................................... 98
Preparing the Target Boards ................................................................... 99
Starting an X Session ........................................................................... 100
Running the Mesa Demos .................................................................... 100
Stopping an X Session .......................................................................... 100
Running the X Server in the Direct Rendering Mode ................................. 100
Configuring the Kernel ......................................................................... 101
Enabling Direct Rendering in the X Server Configuration File ........... 101
Building XFree86 Demo System with the Direct Rendering Enabled . 102
How to Check That the Direct Rendering Mode is Used ..................... 102
Running the Mesa Demos with the Direct Rendering Enabled ............ 102
APPENDIX A GLOSSARY ............................................................................................ 103
INDEX ............................................................................................................ 107
LynxOS User’s Guide vii

Contents
viii LynxOS User’s Guide

Preface
This LynxOS User’s Guide provides information about basic system administration
and kernel configuration for the LynxOS real-time operating system from
LynuxWorks, Inc.
This document assumes that its audience has a basic understanding of the UNIX
environment.
While this document provides information for a variety of readers—system
administrators, network administrators, developers, and end-users of
LynxOS —many of the tasks described in it require root privilege or access to
other information typically given only to system administrators.
For More Information

For information on the features of LynxOS, refer to the following printed and
online documentation.
• LynxOS Release Notes
This printed document contains details on the features and late-breaking
information about the current release.
• LynxOS Installation Guide
This manual details the installation instructions and configurations of
LynxOS.
• Writing Device Drivers for LynxOS
This guide contains details on writing device drivers for LynxOS.
LynxOS User’s Guide ix

Preface
• LynxOS Networking Guide

This guide contains configuration and usage information on the
networking capabilities in LynxOS. It provides information on supported
protocols such as TCP/IP, NFS, and DHCP.
• Online information
Information about commands and utilities is provided online in text
format through the man command. For example, a user wanting
information about the GNU compiler would enter the following syntax,
where gcc is the argument for information about the GNU compiler:
man gcc
Other documentation listed here may also be online. In case of a
discrepancy between the printed and the online version, the online
version is correct.
Other documents that might be useful are the following:
• Using GNU CC
• LynxOS Total/db
Typographical Conventions
The typefaces used in this manual, summarized below, emphasize important
concepts. All references to filenames and commands are case-sensitive and should
be typed accurately.
Kind of Text Examples
Body text; italicized for emphasis, new Refer to the LynxOS User’s Guide.
terms, and book titles
Environment variables, filenames, ls

functions, methods, options, parameter -l
names, path names, commands, and myprog.c
computer data /dev/null
x LynxOS User’s Guide

Special Notes
Kind of Text Examples
Commands that need to be highlighted login: myname

within body text, or commands that must be # cd /usr/home
typed as is by the user are bolded.
Text that represents a variable, such as a cat <filename>

filename or a value that must be entered by mv <file1> <file2>
the user, is italicized.
Blocks of text that appear on the display Loading file /tftpboot/shell.kdi

into 0x4000
screen after entering instructions .....................
or commands File loaded. Size is 1314816
Copyright 2000 LynuxWorks, Inc.
All rights reserved.
LynxOS (ppc) created Mon Jul 17

17:50:22 GMT 2000
user name:
Keyboard options, button names, and Enter, Ctrl-C

menu sequences
Special Notes
The following notations highlight any key points and cautionary notes that may
appear in this manual.
NOTE: These callouts note important or useful points in the text.
CAUTION! Used for situations that present minor hazards that may interfere with
or threaten equipment/performance.
LynxOS User’s Guide xi

Preface
Technical Support
LynuxWorks Support handles support requests from current support subscribers.
For questions regarding LynuxWorks products or evaluation CDs, or to become a
support subscriber, our knowledgeable sales staff will be pleased to help you
(http://www.lynuxworks.com/corporate/contact/sales.php3).
How to Submit a Support Request

When you are ready to submit a support request, please include all the following
information:
• First name
• Last name
• Your job title
• Phone number
• Fax number
• E-mail address
• Company name
• Address
• City, state, ZIP
• Country
• LynxOS or BlueCat Linux version you are using
• Target platform (for example, PowerPC or x86)
• Board Support Package (BSP)
• Current patch revision level
• Development host OS version
• Description of problem you are experiencing
xii LynxOS User’s Guide

Where to Submit a Support Request
Where to Submit a Support Request
By E-mail:
Support, Europe tech_europe@lnxw.com

Support, worldwide except Europe support@lnxw.com
Training and courses USA: training-usa@lnxw.com
Europe: training-europe@lnxw.com
By Phone:
Training and courses USA: +1 408-979-4353

Europe: +33 1 30 85 06 00
Support, Europe +33 1 30 85 93 96
(from our Paris, France office)
Support, worldwide except Europe and Japan +1 800-327-5969 or
(from our San José, CA, USA headquarters) +1 408-979-3940
Support, Japan +81 33 449 3131
By Fax:
Support, Europe +33 1 30 85 06 06

(from our Paris, France office)
Support, worldwide except Europe and Japan +1 408-979-3945
(from our San José, CA, USA headquarters)
Support, Japan +81 22 449 3803
LynxOS User’s Guide xiii

Preface
xiv LynxOS User’s Guide

CHAPTER 1 Overview
This user's guide for LynxOS is intended for use by system integrators and
software engineers.
• Chapter 1 provides the overview of the individual chapters.
• Chapter 2 provides a brief description of LynxOS, including its key
features.
• Chapter 3 describes the LynxOS architecture.
• Chapter 4 describes the Symmetric Multiprocessing feature supported in
LynxOS 5.0.
• Chapter 5 describes LynxOS conformance to the POSIX.13 PSE53
system profile.
• Chapter 6 describes shared libraries.
• Chapter 7 explains how to customize the default LynxOS kernel
configuration after initial installation.
• Chapter 8 provides information about creating Kernel Downloadable
Images (KDIs).
• Chapter 9 explains the Linux Application Binary Interface (ABI)
compatibility feature of LynxOS that allows Linux binary applications to
run under LynxOS.
• Chapter 10 describes XFree86 and LessTif.
LynxOS User’s Guide 1

Chapter 1 - Overview
2 LynxOS User’s Guide

CHAPTER 2 Understanding LynxOS
What LynxOS Is
LynuxWorks, Inc. has been the premier developer of POSIX-conformant real-time
operating systems for over 18 years. The company’s flagship product, called
LynxOS, is in use in hundreds of thousands of installations where high reliability
and hard real-time determinism are essential.
LynxOS Environment
The LynxOS product uses the following environment:
• Host platform for cross-development:
- Windows XP Professional
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5.1
- Red Hat Enterprise Linux 5.2
• Target system—Usually purpose-built computers running a custom-
configured BSP for that board. When the actual target systems are not yet
available, development can be done using “reference platforms” (that is,
commercially available computers for which a BSP already exists).

Chapter 2 - Understanding LynxOS
What LynxOS Offers
Advantages of LynxOS
This release of LynxOS continues to offer the following advantages:
• UNIX-like environment— The LynxOS operating system is similar to
UNIX. Applications use processes and threads, make system calls, and
use device drivers. The product can run a shell on a serial port for a
developer to interact directly with the target machine. It also has device
drivers to permit mounting an external disk drive to facilitate testing and
data capture.
• POSIX-conformant interfaces—LynxOS provides conformance with
IEEE 1003.1-2004 (POSIX.1) interfaces and services specified by the
POSIX 1003.13 PSE53 profile (Dedicated Realtime System). A number
of services from the PSE54 profile (Multi-Purpose Realtime System) are
also supported.
The supported POSIX extensions include threads, priority scheduling,
real-time signals, clocks and timers, semaphores, message passing,
shared memory, asynch and synch I/O, memory locking, and others.
• Maturity and stability— LynxOS is an embedded real-time operating
system that has been rigorously exercised through millions of
deployments and is the foundation of multiple safety-critical systems.
• Networking support—LynxOS includes a full-featured networking stack
to enable communication via the standard Internet protocols. The
networking features are accessible via the standard socket API. Utilities
are provided for network configuration, troubleshooting, and
management.
New Features
The following new features are included in LynxOS 5.0:
• Toolchain GCC/G++ 3.4.3
• GNAT 3.4.3 support
• GDB 6.5
• POSIX 1003.13-2003 PSE53 support

New Features
• Partial POSIX 1003.13-2003 PSE54 support—

POSIX_C_LANG_WIDE_CHAR, POSIX_WIDE_CHAR_IO,
POSIX_USER_GROUPS, and XSI_DYNAMIC_LINKING
• Red Hat Enterprise Linux 3-compliant Linux ABI (GLIBC 2.3.3)

• Up to 2 GB of OS-managed memory (RAM) on x86
• Up to 1.5 GB on PowerPC
• 10/100/1000 Mb Ethernet support
• Symmetric Multiprocessing (SMP) — A single kernel may be built to
support both single and multiple core systems
• Support for the execution of threads that use the Altivec instruction set
• Configurable clock timer
• Multithreaded shared and nonshared libraries
• FAT 16/32 file system support
• Freeblocks functionality support
• Enhanced networking support
- TCP/IP
o IPv4/IPv6 TCP/IP stack per RFC-791
o User Datagram Protocol (UDP) per RFC-768
o Transmission Control Protocol (TCP) per RFC-793
o Explicit Congestion Notification for TCP per RFC-3168
o Internet Control Message Protocol (ICMP) per RFC-792
o Address Resolution Protocol (ARP) per RFC-826
o IP Security (IPSec) per RFC-2401
o Internet Protocol version 4 per RFC-2474 (Definition of the
Differentiated Services Field [DS Field] in the IPv4 Header)
o Internet Standard Subnetting Procedure per RFC-950
o Broadcasting Internet Datagrams per RFC-919
o Broadcasting Internet Datagrams In The Presence Of Subnets per
RFC-922

Chapter 2 - Understanding LynxOS
o Internet Group Management Protocol, Version 3 specification per

RFC-3376
o Prioritized Messages per IEEE STD 802.1p
o Virtual LAN Support per IEEE STD 802.1q
o File Transfer Protocol (FTP) per RFC-414
o Ethernet bridging per IEEE STD 802.1d
- NFS
o NFSv2 client/server
- Simple Network Management Protocol (SNMP) versions 1, 2c, and 3
per RFCs 1901-1908, 2571-2575
- TLS/SSL—transport layer security in the form of OpenSSL support
- TFTP
o Trivial File Transfer Protocol (TFTP) per RFS-1350 and associated
RFC-2347, RFC-2348, RFC-2349, and RFC-1785
o TFTP client
- OpenSSH
- Support for the following daemons/utilities: FTP client, DHCP client
and server, DNS client, NTP client, and TCP wrappers
- NTP 4.0
• Luminosity IDE for cross-compiling C and C++ programs for execution
on the target system and for debugging C and C++ programs
• The SpyKer trace tool which is designed to support high performance
event tracing of LynxOS kernel and applications
• Sun J2SE JVM support via Linux ABI for x86
• X Windows support
- XFree86 4.3.0
- MESA 6.2.1
- LessTif 0.93.36
For the most recent features of LynxOS, always refer to the current
LynxOS 5.0 Release Notes.

CHAPTER 3 LynxOS Architecture
The software that runs on the target system is generally classified as either System
Software (that is, the LynxOS operating system) or Application Software.
System Software includes parts of the operating system, such as device drivers,
which execute in processor supervisor mode. It also includes System Applications,
such as init and the various networking daemons and tools, which execute in
operating system root privileges.
LynxOS Operating System

Figure 3-1 shows the LynxOS software architecture. LynxOS is a
UNIX- style operating system designed to allow multiple real-time applications of
different criticality levels to execute concurrently on the same processor.
The LynxOS operating system is designed to be independent of its underlying
hardware platform. A unique Board Support Package (BSP) and CPU Support
Package (CSP) provide the hardware-specific services to LynxOS. The
application's only interaction with LynxOS is through its documented Application
Programming Interface (API).

Chapter 3 - LynxOS Architecture
Figure 3-1: LynxOS Architecture
NOTE: LynxOS comprises all the components that appear in the region labeled
System Software in this diagram.
The CSP, device drivers, BSP, and configuration tables may be different on
different boards or microprocessors.
The Application Software is usually supplied by the system integrator.
System Services
The system services are linked with the application code (C or C++) and run in
processor user mode.
Application Programming Interfaces (API) include:
• POSIX API LynxOS provides services as specified in the POSIX 1003.13-2003

standard profile PSE53.
• File System LynxOS provides a file system with a POSIX API

Kernel
• IEEE Floating LynxOS provides services to configure floating point responses

Point Services following the C-99 and POSIX 1003.13 standards.
• Networking LynxOS provides the standard socket API for networking services.
Services
Kernel
The LynxOS Kernel is statically linked with the CSP, BSP, and Static Device
Drivers to create the LynxOS operating system. During initialization, Dynamic
Device Drivers are dynamically linked with LynxOS and effectively become part
of the operating system.
Boot Code
The Boot Code boots the host processor and performs the appropriate level of
power on self test (POST) to assure correct operating conditions of a limited set of
hardware devices. The Boot Code is not part of LynxOS. Instead, it is usually
provided as a special set of firmware on the target board.
CSP
The CSP contains all the processor family-specific routines, including the MMU,
Floating Point, and processor exception handlers. The CSP routines are linked with
the LynxOS Kernel.
BSP and DRM

The BSP contains routines for initializing and controlling hardware on the target
system. The primary responsibilities of the BSP are:
• Interface with Boot and Shutdown software
• Establish virtual address map for onboard I/O
• Interface with the interrupt controller
• Provide default handlers for error-signaling interrupts
• Interface with the PCI controller
• Interface with the system time (tick timer)

Chapter 3 - LynxOS Architecture
The PCI Device Resource Manager (DRM), shown with the BSP above, is
platform-independent.
The primary responsibilities of the PCI DRM are:
• Locate the PCI devices
• Manage ownership of PCI devices
• Map devices into virtual address space
• Provide access to the PCI configuration space
The BSP and the DRM are linked with the LynxOS Kernel.
Static Device Drivers

The Static Device Drivers are software components that isolate specific details of
hardware devices from Application Software components. Items such as hardware
dependent interrupt handlers (for example, network interfaces or disk devices) and
kernel threads are added to the kernel with device drivers. Static device drivers are
linked with the kernel.
Static Device Info Files

The Static Device Info Files are used to configure the Static Device Drivers for
devices available in the target system. There are one or more info files per device
driver. The static device info files are linked with the LynxOS Kernel.
Dynamic Device Drivers

The Dynamic Device Drivers are hardware access routines for optional devices on
the target system. These device drivers are stored in the file system and installed
after the LynxOS Kernel is booted.
Dynamic Device Info Files

The Dynamic Device Information Files are used to configure the Dynamic Device
Drivers for optional devices on the target system. There can be one or more
information files per device driver. These device info files are stored in the file
system and installed after the LynxOS Kernel is booted.

CHAPTER 4 Symmetric Multiprocessing
(SMP)
LynxOS 5.0 can run on boards that have more than one CPU core. The LynxOS 5.0
introduces support of the Symmetric Multiprocessing (SMP) feature.
To provide SMP support in LynxOS, some changes are made to the LynxOS kernel
and user-level libraries. It has some impact on the custom kernel and user-level
development process.
This chapter briefly describes these areas of changes and provides impact details.
Scheduling
There are two approaches to organize thread run queues in the SMP environment:
• One run queue per CPU
• One run queue for all CPUs
This section describes both approaches, their advantages and disadvantages, and
gives explanation for the approach used in LynxOS.
Scheduling in General Purpose OS'es

When a thread runs on a CPU, it brings its relevant data into the CPU cache,
allowing it to run faster on that CPU. If it then gets transferred to a different CPU,
it won't be able to run as fast on the new CPU for some time. The transfer also
causes a lot of system bus traffic, as the new CPU brings the thread's data into
caches and the old CPU flushes the thread's modified data back into memory, thus
slowing down the entire system. It is therefore beneficial for performance to
prevent frequent thread jumping between CPUs.
General purpose operating systems, such as Linux, FreeBSD, and Solaris achieve
this by maintaining one thread run queue per CPU. Each thread tends to stay on

Chapter 4 - Symmetric Multiprocessing (SMP)
one CPU for a relatively long period of time. Once in a while, the scheduler
balances the CPU load, moving threads from heavily loaded CPUs to lightly
loaded ones. This approach is called many run queues.
The many run queues approach is good for performance. However, it is lacking
from the real-time response perspective: once a thread becomes ready to run, it has
to wait for its CPU to finish running higher priority threads, if any, even if another
CPU in the system is idle or running lower priority threads. The load balancing
occurs too infrequently and may be no help at all (for example, in case other CPUs
are busy with a lot of lower priority threads).
As an additional feature, the scheduler may allow the user to bind a thread to one
CPU or a set of CPUs. Such threads may not be moved to other CPUs even by load
balancing. This feature is called CPU affinity. CPU affinity's effect on both
performance and real-time response is even more pronounced than that of many
run queues, however, unlike the run queues, CPU affinity is voluntary and optional.
The user may choose whether to employ it or not after careful consideration and
testing.
Scheduling in LynxOS
Being a hard real-time operating system with a strict priority preemptive scheduler,
LynxOS values real-time response higher than performance. Therefore, the one run
queue approach was chosen. There is only one thread run queue per system (or per
partition, if LynxOS version provides partitioning). When a thread becomes ready
to run, the scheduler immediately runs it on one of the lowest priority CPUs (that
is, CPUs running threads of the lowest priority among all threads in the
system/partition). Only if the CPU that the thread ran on last is one of the lowest
priority CPUs, the scheduler will keep the thread running on that CPU.
This approach guarantees that in a system with N CPUs, the N highest priority
threads are running at any given moment. On the other hand, threads move
between CPUs more frequently than in the many run queues approach, thus
reducing the overall system performance.
LynxOS release 5.0 does not support CPU affinity. However, this feature could be
added later by patches or subsequent OS releases.

SMP User-Level Impact
SMP User-Level Impact

There are no specific requirements to user-level applications and libraries to work
in the SMP environment. SMP introduction caused just a few user visible changes.
These changes are described in this section
Custom Applications
Most of the custom applications work fine in the SMP environment without any
modifications. In the SMP environment, processes and threads are safely
synchronized by primitives (such as POSIX mutexes, semaphores, etc.) the same
way as it is done in the case of uniprocessing.
Additionally, atomic operations and memory barriers can be used to perform
various types of synchronization. This section briefly describes these techniques.
Refer to LynxOS 4.x to LynxOS 5.0 Migration Kit Guide for details.
For general information about programming in the multiprocessing environment,
refer to the following Internet address:
http://docs.sun.com/app/docs/doc/816-5137/6mba5vpl5?a=view.
Atomic Variables and Operations

LynxOS provides the atomic variable type, which is an integer value stored in
RAM, plus a number of hardware-assisted atomic read-modify-write and
test-and-set operations on atomic variables. Atomic operations on atomic variables
are uninterruptible system-wide, and are therefore useful for synchronization and
other purposes both in single and multiple-CPU environments.
Atomic operations are typically much slower than the corresponding non-atomic
operations.
Memory Barriers
In a multi-processor environment, the order of CPU memory accesses (loads and
stores) should be enforced in some situations (for example, before a lock release).
LynxOS provides a number of calls to enforce the CPU memory access order,
called memory barriers.

Chapter 4 - Symmetric Multiprocessing (SMP)
The Number of CPUs in the System

The programmer can find out the number of CPUs in the system by using the
sysconf(3) library call. See the sysconf(3) manual page for more
information.
From the command shell, the number of CPUs in the system can be determined
using the sysctl(8) utility, for example as follows:
$ sysctl hw.ncpu
hw.ncpu: 2
$
Utilities
The ps utility displays which CPU the thread is running on (for currently running
threads), or which CPU the thread ran on last (for other threads). Because of the
priority preemptive scheduling in LynxOS, threads move from CPU to CPU
frequently. The CPU information displayed by the utilities is a snapshot of the state
of the system, and does not reflect all the system state changes during the execution
of the utility program.

CHAPTER 5 Support for POSIX.13 PSE53
System Profile in LynxOS
What is POSIX.13?
The IEEE 1003.13-2003 standard, also known as POSIX.13, focuses on defining
real-time and embedded application environments.
The POSIX.13 standard captures existing commercial practice to introduce system
profiles, each such profile comprising a set of services and application
programming interfaces that an operating system supports.
The intent of this chapter is to offer just a general idea about the POSIX standards
themselves and to give an outline of LynxOS support for those. No attempt is made
here to replace the IEEE documents, which are the ultimate source of information
about the POSIX standards and the behavior of the facilities an operating system
provides. Therefore, to acquaint themselves with such details, readers are urged to
consult the IEEE publications.
An Overview of the POSIX.1 Standard

The family of POSIX standards provides the foundation for implementation of the
system services and application programming interfaces for the majority of modern
operating systems.
The IEEE 1003.1-2004 standard, also commonly referred to as the POSIX.1
standard, summarizes all historical versions of IEEE 1003.x standards. The latter
documents describe various facilities that the existing operating systems provided,
including, but not limited to, process management, threading mechanisms, real-
time extensions, shell, and utilities.

Chapter 5 - Support for POSIX.13 PSE53 System Profile in LynxOS
Nowadays, all these parts are rolled into a single set of documents that consists of
four parts:
• Part 1: Base Definitions
• Part 2: System Interfaces
• Part 3: Shell and Utilities
• Part 4: Rationale (informative)
These IEEE publications are available for purchase in electronic form from the
IEEE Web site (http://www.ieee.org) or in printed form from the Open Group
bookstore (http://www.opengroup.org).
Briefly speaking, the set of facilities that the POSIX.1 standard defines are those
ones that are assumed as existing and supported in the context of the POSIX-
conformant operating system. It is this assumption that makes the source code
application portability across different platforms possible.
The kernel services and library calls provided by this release of the LynxOS
operating system are implemented in accordance with the requirements and
specifications of the POSIX.1 standard.
The POSIX.13 System Profiles

The POSIX.13 standard specifies four levels of functionality to which a real-time
operating system can conform. These levels are defined in terms of the so-called
real-time system profiles. A profile is a collection of certain subsets of the
POSIX.1 standard that are used to define an application environment. The
POSIX.13 profiles are denoted as PSE51 for a minimal system through PSE54 for
a full-fledged operating system featuring multiprocess capabilities, networking,
interactive shells, utilities, and development tools. The four profiles are commonly
described as shown in Table 5-1:
Table 5-1: The POSIX.13 Profiles Description
Profile Description
PSE51 Minimal Realtime System Profile

PSE52 Realtime Controller System Profile
PSE53 Dedicated Realtime System Profile
PSE54 Multi-Purpose Realtime System Profile

The POSIX.1 Options
It is important to understand that the POSIX.13 standard itself does not define any
operating system interfaces or APIs. Instead, this standard specifies which
interfaces need to be supported by an operating system that claims conformity to
one of the system profiles. Specification of these interfaces is provided by another
document, the POSIX.1 standard. Please see the previous section in this chapter for
more details about the POSIX.1 standard.
LynxOS conforms to the PSE53 system profile.
The subsets of interfaces that need to be supported by a conforming
implementation are defined either in terms of POSIX.1 options or as the so-called
POSIX.13 Units of Functionality. Details on the POSIX.1 options and the Units of
Functionality are provided later in this chapter.
The POSIX.1 Options

The POSIX.1 options are groups of facilities that an operating system can support.
The presence of a particular option in an implementation is indicated by presence
of a preprocessor constant with the _POSIX prefix in the system header files. In
LynxOS, these constants reside in the header file
usr/include/unistd_options.h.
The following list itemizes the POSIX.1 options required in the PSE53 system
profile:
• _POSIX_ASYNCHRONOUS_IO
• _POSIX_CLOCK_SELECTION
• _POSIX_CPUTIME
• _POSIX_FSYNC
• _POSIX_MAPPED_FILES
• _POSIX_MEMLOCK
• _POSIX_MEMLOCK_RANGE
• _POSIX_MEMORY_PROTECTION
• _POSIX_MESSAGE_PASSING
• _POSIX_MONOTONIC_CLOCK
• _POSIX_NO_TRUNC
• _POSIX_PRIORITIZED_IO
• _POSIX_PRIORITY_SCHEDULING

• _POSIX_REALTIME_SIGNALS
• _POSIX_SEMAPHORES
• _POSIX_SHARED_MEMORY_OBJECTS
• _POSIX_SPAWN
• _POSIX_SPORADIC_SERVER
• _POSIX_SYNCHRONIZED_IO
• _POSIX_THREAD_ATTR_STACKADDR
• _POSIX_THREAD_ATTR_STACKSIZE
• _POSIX_THREAD_CPUTIME
• _POSIX_THREAD_PRIO_INHERIT
• _POSIX_THREAD_PRIO_PROTECT
• _POSIX_THREAD_PRIORITY_SCHEDULING
• _POSIX_THREAD_PROCESS_SHARED
• _POSIX_THREAD_SPORADIC_SERVER
• _POSIX_TIMEOUTS
• _POSIX_TIMERS
• _POSIX_TRACE
• _POSIX_TRACE_EVENT_FILTER
• _POSIX_TRACE_LOG
For definition of each POSIX.1 option in terms of POSIX.1 interfaces, refer to the
document 1003.13 IEEE Standard for Information Technology— Standardized
Application Environment Profile (AEP)—POSIX® Realtime and Embedded
Application Support.
The Units of Functionality in POSIX.13

Sometimes, the specifics of the real-time and embedded systems dictate that no
ready-made POSIX.1 option exists that would define just the required
functionality. To provide for such cases, the POSIX.13 standard introduces the
notion of a Unit of Functionality — a collection of interfaces that the
implementation can offer.

Implementation-Defined Functionality
The following list itemizes the Units of Functionality required in the PSE53 system
profile:
• POSIX_C_LANG_JUMP
• POSIX_C_LANG_MATH
• POSIX_C_LANG_SUPPORT
• POSIX_DEVICE_IO
• POSIX_EVENT_MGMT
• POSIX_FD_MGMT
• POSIX_FILE_LOCKING
• POSIX_FILE_SYSTEM
• POSIX_MULTI_PROCESS
• POSIX_NETWORKING
• POSIX_PIPE
• POSIX_SIGNALS
• POSIX_SIGNAL_JUMP
• POSIX_SINGLE_PROCESS
• POSIX_THREADS_BASE
• XSI_THREAD_MUTEX_EXT
• XSI_THREADS_EXT
For definition of each PSE53 Unit of Functionality in terms of POSIX.1 interfaces,
refer to the document 1003.13 IEEE Standard for Information Technology—
Standardized Application Environment Profile (AEP)—POSIX® Realtime and
Embedded Application Support.
Implementation-Defined Functionality
For some interfaces, the POSIX.1 standard leaves some uncertainty as to how the
facility needs to behave within a particular implementation. In such cases, it is said
that the behavior is implementation-defined.
Refer to “Example: Application-Managed Thread Stacks” below for the example
of implementation-defined functionality.
For the LynxOS operating system, a detailed description of the implementation-
defined features can be found in the POSIX 1003.13-2003 PSE53 Conformance
Document.

Example: Application-Managed Thread Stacks

LynxOS offers the functionality of fixed stacks also referred to as the application-
managed thread stacks. This facility is appropriate for use by applications in the
situation when the thread stack must be placed into some particular region of
memory.
Support for the fixed stacks is provided via the stackaddr attribute of a POSIX
thread and via the following POSIX interfaces the standard C library exports:
• pthread_attr_setstackaddr()
• pthread_attr_getstackaddr()
• pthread_attr_setstack()
• pthread_attr_getstack()
• pthread_attr_setstacksize()
• pthread_attr_getstacksize()
For more information about the application-managed thread stacks functionality,
refer to the description for these functions provided in the document Standard for
Information Technology—Portable Operating System Interface (POSIX®), System
Interfaces.
When using the fixed stacks facility, an application allocates a contiguous region of
memory using a call to malloc() or mmap() and then passes the address of this
region to the thread attribute by calling pthread_attr_setstackaddr() or
pthread_attr_setstack().
The standard does not dictate any particular relationship between the address
passed to the thread attribute and the actual place where the thread stack area
would reside in the process virtual address space. The LynxOS implementation is
based on an additional assumption that the address passed by an application is the
low (base) address of the thread stack.
The POSIX.26 Standard

The overwhelming majority of the interfaces that the PSE53 system profile
requires are specified by the POSIX.1 standard. One interface defined by yet
another standard, the IEEE 1003.26, also commonly referred to as the POSIX.26
standard, is required in the PSE53 profile. This is the posix_devctl() function
exported by the LynxOS standard C library. Please refer to the online manual page
for the posix_devctl() routine for more information.

Limitations of PSE53 Support in LynxOS
Limitations of PSE53 Support in LynxOS

This release of LynxOS does not support the _POSIX_TRACE,
_POSIX_TRACE_EVENT_FILTER, and _POSIX_TRACE_LOG options.
The POSIX System Parameters

The POSIX.1 standard defines a few dozens system parameters that specify the
amount of resources available to an application. For the majority of such resources,
the standard requires that the parameter value be limited by a certain minimum or
maximum. These system parameters are implemented as the C language
preprocessor constants placed into the system header limits.h. For the complete
list of such parameters and their minimum (and maximum) values, refer to the
description of the limits.h header in Standard for Information Technology—
Portable Operating System Interface (POSIX®), Base Definitions.
The LynxOS implementation of the limits.h header file takes into account the
requirements and limitations imposed by the standard. Most of those parameters
are not user-configurable.
Some of them, however, are, and the next section explains the subtleties of
handling such system parameters in LynxOS.
Runtime Invariant Values

The POSIX standard allows certain system parameters to vary depending on a
specific instance of a specific implementation, although such values are runtime
invariant. For example, in the LynxOS kernel, the number of file descriptors per
process is specified at kernel build time, but may not legally be changed for a
running kernel. Such entities are said to be indeterminate ones.
Within this release of LynxOS, a number of such indeterminate values exist. These
values include:
• AIO_LISTIO_MAX
• AIO_MAX
• CHILD_MAX
• OPEN_MAX

• STREAM_MAX
• SYMLOOP_MAX
• MQ_OPEN_MAX
• SEM_NSEMS_MAX
• TIMER_MAX
For obtaining the values of these variables specific to an instance of the
LynxOS kernel, use the sysconf() interface. Please see the online manual page
for the sysconf() routine for more information about this interface.
Some of the values mentioned above can be configured by setting appropriate
constants in the BSP-specific uparam.h file. During the kernel build, these
values are checked to comply with POSIX requirements and a warning is issued if
an incorrectly set parameter may result in a non-POSIX system.
For example, when the NTIMERS value in uparam.h is set incorrectly, the
following warning is issued:
#warning "NTIMERS value is less than minimum value required by POSIX"
Table 5-2 summarizes the runtime invariant values, the limitations imposed by the
standard, and the names of preprocessor constants in the uparam.h header.
Table 5-2: Configurable System Parameters in LynxOS
POSIX
Runtime Invariant
Constant in uparam.h Minimum
Value
Value
CHILD_MAX LIM_NPROC 25
MQ_OPEN_MAX LIM_MSGQS 8
OPEN_MAX USR_NFDS 8
SEM_NSEMS_MAX LIM_SEMAPHORES 256
STREAM_MAX USR_NFDS 8
SYMLOOP_MAX MAXSYMLINKS 8
TIMER_MAX LIM_NTIMERS 32

Partial PSE54 Support in LynxOS
Partial PSE54 Support in LynxOS

Although LynxOS does not claim conformance to the PSE54 system profile, the
following Units of Functionality that are not required in the PSE53 system profile
but do belong to PSE54 are supported:
• POSIX_C_LANG_WIDE_CHAR
• POSIX_WIDE_CHAR_IO
• POSIX_USER_GROUPS
The 1003.13 IEEE Standard for Information Technology— Standardized
Application Environment Profile (AEP)—POSIX® Realtime and Embedded
Application Support defines each of these options in terms of POSIX.1 interfaces.


CHAPTER 6 Shared Libraries
Users may have an application that relies on shared libraries. Or perhaps users are
considering using shared libraries for an embedded application.
This chapter describes shared libraries and explains whether they should be used,
how they are used, and how they are built.
Overview
A shared library is a collection of routines, organized so that code can be shared
among processes; its primary goal is to reduce system and disk memory usage.
LynxOS supports tools to create and use C and C++ dynamic ELF shared libraries
on all of its supported platforms.
Shared library development is supported by cross development tools.
The term shared library is not entirely accurate when used with the ELF/SVR4
implementation. The correct term is shared object, because shared libraries are not
archive (ar) libraries. They have more in common with partially linked (ld -r)
object files. Shared objects can be identified by the .so suffix. This document,
however, uses the term shared library when referring to shared objects.
Compatibility between different revisions of a library is easy to maintain, as long
as the libraries are functionally compatible; applications linked with the library do
not need to be relinked in order to use the newer version.
No source code changes are necessary when making a shared library. Object files
that are to be part of the shared library must be compiled as Position Independent
Code (PIC) using the -fPIC -mshared -shared compiler flags.
The LynxOS implementation also includes dlopen()/libdl.so support. This
library provides functions that allow users to open, close, and find symbols in an

Chapter 6 - Shared Libraries
arbitrary shared library, even if the application in use has not been linked with the
library. For more details, see the dlopen() man page.
Creating Shared Libraries by Default

Some ELF-based systems, such as Linux, create shared objects by default, and
make it necessary to provide a special option to the linker to produce statically
linked objects. LynxOS takes the reverse approach. In LynxOS, the linker produces
statically linked objects by default. To produce executables that link with shared
objects at run-time, you must link with the option -mshared.
Single/Multithreaded Applications and Shared Libraries

When an application links with a shared object, it is important to note if the
application uses single-threaded processes or multithreaded processes. Processes
that create multiple threads (using the system call pthread_create) should only
call thread-safe functions. Thread-safe functions are coded in such a way that they
work correctly even when they are concurrently executed by more than one thread.
LynxOS 5.0 does not provide a separate version of shared libraries for the non-
thread safe case. Libraries in the /lib/thread directory are the same as in
/lib. /lib/thread is maintained just for the backward compatibility.
Lazy Linking
By default, the dynamic linker defers function call resolution to the point when
they are first referenced. The LD_BIND_NOW environment variable can be set to a
nonempty string to cause the dynamic linker to resolve all symbols at the program
startup time.

Effects of Using Shared Libraries
Effects of Using Shared Libraries

In essence, when users modify the contents of a shared library, they modify all the
programs that rely on it, unless they never deploy the new library, or only deploy it
selectively. Using a shared library instead of an ordinary non-shared archive library
may affect the following:
• System Memory Usage
• Disk Space Usage
• Code Maintenance
System Memory Usage

System memory usage is different because multiple processes can share the library
code. The amount of system memory saved (or lost) by using a shared library
depends on three factors:
• The contents of the shared library
• The set of programs that are typically run on the system
• The load on the system
(See “Determining the Use of Shared Libraries” on page 29 for additional details
and several examples).
The following relationships are true in general:
• A shared library consisting of commonly used routines saves more
system memory than one that has many rarely used routines.
Routines and data items in the shared library that are rarely used waste
system memory simply by their lack of use as follows:
- A rarely used routine wastes memory because the entire shared library
resides in memory whenever it is used, regardless of which subset of
routines from the library are actually linked.
- A rarely used data item wastes system memory equal to its size
multiplied by the number of processes currently using the shared
library. This is because each process has its own copy of the data.
• A shared library that is used by a varied and numerous assortment of
programs saves more system memory than a shared library that is used by
only one or two programs.

Multiple concurrent executions of the same program use the same amount
of text memory as does a single execution. The operating system ensures
that the executing text segments of the same program are shared.
Disk Space Usage

Disk space usage is typically lower because a program linked with a shared library
is almost always smaller than the same program linked with an equivalent archive
library. The shared library itself is not a factor in disk space usage because it is
comparable in size to an equivalent archive library.
Consider this simple “hello world” program:
#include <stdio.h>
main()
{
printf("Hello, world!\n");
}
The printf() function is included in the C library. If the program is linked to

the static C library, the resulting program executable file is close to 36 kilobytes:
# gcc -o hellostatic hello.c
# ls -l hellostatic
-rwxr-xr-x 1 root 36014 Jan 24 01:01 hellostatic*
If the same program is linked with the shared C library, then it is only about
5 kilobytes:
# gcc -mshared -o hellodynamic hello.c
# ls -l hellodynamic
-rwxr-xr-x 1 root 5133 Jan 24 01:02 hellodynamic*
In many cases, using shared libraries provides a considerable difference in size
compared to static libraries.
Code Maintenance
Maintaining programs that use a shared library is somewhat easier than
maintaining programs that use an archive library because if an error in the library is
fixed, only the shared library needs to be remade. The programs do not need to be
re-linked with the library because the operating system maps the shared library

Determining the Use of Shared Libraries
code into their address spaces at run time. In effect, modifying the contents of a
shared library modifies all of the programs that use it.
NOTE: The above statements hold true only when the change to the shared library
is backward compatible. Compatibility problems can be avoided as long as the
shared library can be built using the guidelines described later in this chapter. For
bug-fixes, compatibility is often automatic. For changes that are broader in scope,
adherence to the guidelines may become challenging or impractical.
Determining the Use of Shared Libraries

In order to decide whether or not to use shared libraries, users must take the
following factors into consideration:
• The number of different applications that are to run concurrently on the
target system
• The percentage of the library code that applications use
• The size of the library’s data and bss sections
• The amount of RAM available on the target system
• The amount of disk, flash, or ROM space available on the target system
• The ease of updating and fixing bugs on shared libraries
• The possibility of performance degradation if using shared libraries
If a target system is running a single application, multiple instances of a single
application, or multiple different applications (not concurrently), the using of
shared libraries will probably increase memory and disk space usage. If, however,
the target system is running many different applications at the same time (and they
use large portions of the same shared libraries), there may be significant reductions
in memory and disk space usage.
For comparison purposes, the space requirements of three sets of applications are
explored in three pairs of tables that follow. All applications in a given set require a
common library.
In the tables “Space Requirements for a 1 MB Library (X) Used by 6 Applications”
“Space Requirements with a 1 MB Library (Y) Used by 6 Applications” and
“Space Requirements with a 1 MB Library (Z) that Includes Data” space
requirements are shown when the associated library is implemented as a non-
shared library.

In the tables “Space Requirements for 1 MB Shared Library (X) Used by 6

Applications” “Space Requirements with a 1 MB Shared Library Used by 6
Applications” and “Space Requirements with a 1 MB Library (Z) that Includes
Data” space requirements are shown when the associated library is implemented as
a shared library.
Example 1
Each of the applications shown in the next two tables uses half of a 1 MB library,
but uses a different mixture of the library’s routines. Where these applications do
not use a shared library, they require 3 MB of RAM and disk space. When they
employ a shared library, they require only 1 MB of RAM and disk space.
Table 6-1: Space Requirements for a 1 MB Library (X) Used by 6 Applications
Library X Usage Space Requirements for

• library text used by application Library X on Target
text RAM Disk
Static Library X 0 0
Application A • • • • • .5 MB .5 MB
Application B • • • • • .5 MB .5 MB
Application C • • • • • .5 MB .5 MB
Application D • • • • • .5 MB .5 MB
Application E • • • • • .5 MB .5 MB
Application F • • • • • .5 MB .5 MB
TOTALS 3 MB 3 MB

Example 2
Table 6-2: Space Requirements for 1 MB Shared Library (X) Used by 6

Applications
Library X Usage
Space Requirements for
• library X deploys element
Library X on Target
+ library text used by application
text RAM Disk
Shared Library X • • • • • • • • • • 1 MB 1 MB
Application A + + + + + 0 0
Application B + + + + + 0 0
Application C + + + + + 0 0
Application D + + + + + 0 0
Application E + + + + + 0 0
Application F + + + + + 0 0
TOTALS 1 MB 1 MB
Example 2
Each application shown in the next two tables uses 10% of a 1 MB shared library.
Each application uses a different portion of the library, all mutually disjoint. Where
these applications do not use a shared library, they require 0.6 MB of RAM and
disk space (with all six applications running). When using a shared library, they
require 1 MB of RAM and disk space.
This is a worst-case scenario; it is not possible to save any space by using a shared
library for this mix of applications. This example is for illustration purposes only. It
is unlikely that a group of applications would use completely disjoint sets of library
routines.
NOTE: If the unused routines were removed from the shared library, the memory
usage for both shared and non-shared libraries would be the same.

Table 6-3: Space Requirements with a 1 MB Library (Y) Used by 6

Applications
Library Y Usage Space Requirements for

• library text used by application Library Y on Target
text RAM Disk
Static Library Y 0 0
Application A • .1 MB .1 MB
Application B • .1 MB .1 MB
Application C • .1 MB .1 MB
Application D • .1 MB .1 MB
Application E • .1 MB .1 MB
Application F • .1 MB .1 MB
TOTALS .6 MB .6 MB
Table 6-4: Space Requirements with a 1 MB Shared Library Used by 6

Applications
Library Y Usage
• library X deploys element
Library Y on Target
+ library text used by application
text RAM Disk
Shared Library Y • • • • • • • • • • 1 MB 1 MB
Application A + 0 0
Application B + 0 0
Application C + 0 0
Application D + 0 0
Application E + 0 0
Application F + 0 0
TOTALS 1 MB 1 MB

Example 3
The preceding examples assume that the library contains no data or bss
sections. While this is the best way to build a shared library, it is not always
possible to do so.
Due to the inability of applications to share data, the data and bss sections of a
shared library are not treated the same way as the text section: Every process
gets a full copy of the data and bss sections whether it uses all of it or not.
Example 3
In the applications shown in the next two tables, the issues surrounding bss and
data section utilization in a shared library are illustrated. Both shared and non-
shared versions of the same library contain 0.5 MB of text, 0.3 MB of data,
and 0.2 MB of bss. Each application uses forty percent of the text and forty
percent of the data and bss sections.
In the case of the non-shared library (the table below), memory usage is 2.4 MB
and disk usage is 1.9 MB. In the case of the shared library (the second table), the
memory usage has increased to 3.5 MB, while the disk usage has dropped to
0.8 MB.
Table 6-5: Space Requirements with a 1 MB Library (Z) that Includes Data
Library Z Usage
• library text/data/bss used by
Library Z on Target
Type application
text data bss RAM Disk
Static Library Z 0 0
Application A • • • • .4 MB .4 MB
Application B • • • • .4 MB .4 MB
Application C • • • • .4 MB .3 MB
Application D • • • • .4 MB .2 MB
Application E • • • • .4 MB .3 MB
Application F • • • • .4 MB .3 MB
TOTALS 2.4 MB 1.9 MB

Table 6-6: Space Requirements with a 1 MB Library (Z) that Includes Data
Library Z Usage
• library text/data/bss
Space
+ library data/bss used by application
Requirements for
- library data/bss allocated but not used by
Type Library Z on Target
application
* library text used by application
text data bss RAM Disk
Shared Library Z • • • • • •1 •1 •1 •2 •2 .5 MB .8 MB
Application A * * + + - - - .5 MB 0
Application B * * - + + - - .5 MB 0
Application C * * - - + + - .5 MB 0
Application D * * - - - + + .5 MB 0
Application E * * + - - - + .5 MB 0
Application F * * - + - + - .5 MB 0
TOTALS 3.5 MB .8 MB
1. Shared library occupies disk space only.

2. Shared library bss does not occupy disk space.
In the preceding examples, a well designed shared library may provide significant
savings in memory needed. Savings in an embedded system could mean:
• A given application now fits in the space allowed on board.
• RAM can be decreased (cost savings).
• More space for new features
The preceding examples also show that a well designed shared library may provide
a significant savings in the disk, flash, or ROM space needed. In an embedded
system with tight memory constraints, these savings could mean the following:
• A given application now fits in the space allowed.
• The flash/ROM chip count can be decreased (cost savings).
• The flash/ROM chip size can be decreased (cost savings).
• A disk may not be needed (cost savings).

Choosing Shared Library Contents
Choosing Shared Library Contents

Choosing the contents of a shared library involves more considerations than
choosing the contents of an ordinary non-shared archive library. It is perhaps the
most important factor determining whether or not the shared library decreases
system memory usage.
When choosing routines for the shared library, use the following guidelines:
• It is generally a good idea to include routines such as printf that are
used often by many different programs.
• It is generally a bad idea to include routines that are rarely used. Recall
that when a shared library is used, it is loaded into memory, regardless of
what routines have been linked.
• It is generally a bad idea to include routines that have large amounts of
data. Recall that the data of a shared library is not shared, so each process
that uses the library gets its own copy of the data. Even if a routine is
commonly used, it can still waste space, because any program that does
not happen to use it still gets a copy of its data.
How to Save Space

In order to minimize the space used by a shared library, global data should be
minimized. One technique for doing this is to use local (stack) variables instead of
global variables wherever possible. Another technique is to allocate buffers
dynamically (for example, with malloc()) instead of statically. These are
effectively identical methods of reducing the data section of the shared library.
This is important because each process using the shared library gets its own
separate copy of the data section.
The above space-saving techniques have the added benefit of making maintenance
of the shared library easier by reducing the number of external symbols in the
library. The number of external symbols can be further reduced by explicitly using
static variables wherever possible.
Updating Shared Libraries

The way that shared libraries are designed allows for an application to be updated
(by rebuilding and replacing the target shared library) without the need to relink the
application. This means that bug-fixes or other library changes can be made in the
field without replacing the entire application. This feature of shared libraries may

require extra work on the part of the library designer to ensure that a new library is
compatible with previous versions.
To support compatibility between newer and older versions of the library, shared
libraries use a global offset table to access function calls. This adds one or more
additional instructions to the normal function call process. These extra instructions
produce slightly longer execution times for library calls. In general, the
performance decrease is not measurable.
Libraries Provided
LynxOS provides the following system shared libraries.
Table 6-7: Shared Libraries in the LynxOS Distribution
Library Description
libaltq Alternate Queueing Framework Library

libbsd Network Address Resolution Library
libc Standard C Library
libcrypt DES encryption Library
libcurses Curses Library
libdbposix POSIX-awareness Debugging Library
libdl Dynamic Linker Library
libipsec IPSec Library
libm Standard Math Library
libmd MD5 Message-digest Library
libpcap Packet Capture Library
librpc Sun RPC Library
libstdc++ GNU C++ Support Library
libvcl VxWorks Compatibility Library

Creating Shared Libraries
Creating Shared Libraries

Shared libraries are easy to create. The following example shows how to create a
shared library named myshared.so from the file myshared.c:
# gcc –shared –mshared –o myshared.so myshared.c
The options in this line are:
-shared The object file of this command will be a shared object.

-mshared Any references to other library functions will be to those found in
the LynxOS-provided shared libraries.
-o The following token, myshared.so, is the name of the created
shared library.
The option –shared is used to create a shared object.
Linking to a Shared Library

In order to link with one of the shared libraries supplied by LynxOS, users must
pass the -mshared flag to the linker. Also users can specify the directory to
search shared libraries using the -L <directory> flag.
The following command is used to build the shared linked application.
$ gcc -o <output_file> <source_files> -mshared


w
CHAPTER 7 Customizing the Default

LynxOS Kernel Configuration
This chapter explains how to customize the default LynxOS kernel configuration
after initial installation.
Reasons for Kernel Customization

As users develop applications in the LynxOS environment, they may need to
customize the LynxOS kernel for the following reasons:
• To tune the performance of a LynxOS native development system.
• To remove functionality, such as superfluous device drivers, to conserve
system resources.
• To add functionality, such as networking support or a custom device
driver, to support a specific application.
To facilitate user’s customization decisions, all LynxOS kernel files are located in
the /sys directory. This centralized location of kernel files allows users to build
customized LynxOS kernels quickly and easily.
Customizing for Performance

If LynxOS is being used as a primary development system, it is advantageous to
customize the kernel for improved performance.
The following are some of the common features that can be customized for
enhanced performance:
• Total number of simultaneously-mountable file systems
• Size of the disk cache
• Maximum number of available processes

Chapter 7 - Customizing the Default LynxOS Kernel Configuration
• Number of TCP/IP buffers
Customizing for Size

A user’s application environment may have size and memory constraints that make
it critical to customize the LynxOS kernel. A kernel’s size can be reduced by
performing either or both of these tasks:
• Removing unused device drivers
• Tuning performance characteristics for a more minimal environment
Customizing for Functionality

The third common scenario involves customizing the functionality of the
LynxOS kernel. This includes adding or removing the following components:
• TCP/IP
• NFS
• Simple Kernel Debugger (SKDB)
Users may also need to add their own custom device drivers.
This chapter describes the structure of the LynxOS kernel directory and the process
for adding custom drivers to the build environment. For detailed information on
developing custom device drivers, see Writing Device Drivers for LynxOS.

Overview of the /sys Directory
Overview of the /sys Directory
CAUTION! Read this section before modifying any LynxOS kernel. It contains
important information about the /sys directory file system that is needed to
prevent kernel data corruption and/or loss.
The LynxOS /sys directory contains all the scripts, library archives, and
platform-specific files that users need to customize and rebuild a LynxOS kernel.
The /sys directory has the following file structure:
Table 7-1: /sys Directory Contents
File/Directory Description
Makefile The top-level Makefile.

OBJ_RULES Contains the Makefile rules.
DRV_RULES Contain rules for the device driver Makefiles.
acpi Contains source files for the ACPI subsystem.
bsp Contains the BSP files that are common for all BSPs.
bsp.<bsp_name> Contains the default Board Support Package (BSP) for the main
hardware platforms currently supported by LynxOS. This
directory also contains the particular LynxOS kernel parts for any
given target board. The kernel image is also modified and linked
here.
cfg Contains files that specify each device driver’s entry points.
csp.<csp_name> Contains the CSP-specific files for CPUs currently supported by
LynxOS.
devices Contains the common devices info source code.
devices.<bsp_name> Contains the BSP-specific devices info source code.
dheaders Contains the common devices info declarations.
drivers Contains the common device drivers source code.
drivers.<bsp_name> Contains the BSP-specific device driver source files.
drm Contains source files for the DRM subsystem.

Table 7-1: /sys Directory Contents (Continued)
File/Directory Description
family.<family_name> Contains the CPU family specific files for CPU families
currently supported by LynxOS.
include Contains the kernel header files.
kernel Contains the architecture independent part of the kernel.
lib Contains the kernel and driver library archives (see the following
table, “sys/lib Kernel Library Files”).
misc Contains miscelaneous source files used by the kernel and other
subsystems.
networking Contains source files for the TCP/IP subsystem and NFS driver.
syscalls Contains the table of system calls.
Table 7-2: sys/lib Kernel Library Files
Library Name Description
libmisc.a Miscellaneous support routines

libnfs_server.a NFS server code
libcsp_<cputype>.a CPU Support Package
libfamily_<family_cputype>.a CPU Support Package (CPU family-specific part)
libsyscalls.a System call interface
libdevices.a Common devices
libdevices_<bsp_name>.a BSP-specific devices
libkernel.a Kernel routines
libtcpip.a TCP/IP code (IPv4 and extras)
libdrivers.a Common device drivers
libdrivers_<bsp_name>.a BSP-specific device drivers
Of all the directories in the /sys directory, users are most likely to modify files in
the /bsp.<bsp_name> directory. Users can, however, also modify files in the
following /sys directories:

Accessing and Modifying the Main Kernel Directory
• cfg
• devices
• dheaders
• drivers
These files, however, should be modified only when adding new drivers or when
the functionality of a specific driver needs to be changed.
Accessing and Modifying the Main Kernel Directory

The main directory for customizing and rebuilding a LynxOS kernel is accessed
through the directory $ENV_PREFIX/sys/bsp.<bsp_name>, where
<bsp_name> represents the Board Support Package (BSP) that supports the
targeted hardware (that is, the configuration on which the custom application is to
be deployed).
Overview of /sys/bsp.<bsp_name>
The $ENV_PREFIX/sys/bsp.<bsp_name> directory contains the following
files:
Table 7-3: $ENV_PREFIX/sys/bsp.<bsp_name> Directory Contents
File Description
config.tbl The control file used for adding/removing device drivers.

CONFIG.h An automatically generated header file.
Makefile The target-specific Makefile.
*.o Files with this extension are the prebuilt object files.
net.spec The spec file for the sample KDI. This file lists all files that go into the
sample KDI.
nodetab An automatically generated file describing static device nodes.
sysdevices.h An automatically generated header file.
uparam.h Contains the user-definable kernel parameters from the standard
/usr/include/param.h parameter set.
*.h Files with this extension are the supporting header files.
version.o Contains LynxOS version information.

Rebuilding a Kernel with the make Utility

To rebuild a kernel, change directory to the
$ENV_PREFIX/sys/bsp.<bsp_name> directory and run the make utility with a
specified Makefile <rule> (see Table 7-4), using the following syntax:
$ cd $ENV_PREFIX/sys/bsp.<bsp_name>
$ make <rule>
Makefile rules are defined in the
$ENV_PREFIX/sys/bsp.<bsp_name>/Makefile as follows:
Table 7-4: $ENV_PREFIX/sys/bsp.<bsp_name> Makefile Rules
Rule Description
all Rebuilds a.out (LynxOS kernel) in the current directory.

clean Removes a.out, CONFIG.h, sysdevices.h,
nodetab, and timestamp.o.
install Same as make all.
Incorporating Changes Made in /sys/devices into the Kernel

To incorporate changes made in $ENV_PREFIX/sys/devices into the kernel,
perform the following steps:
1. Change to the /sys/devices directory.
$ cd $ENV_PREFIX/sys/devices
2. Add or update the appropriate device file to the /sys/devices
directory.
3. Rebuild the kernel. For example:
$ make install

Adding/Removing Device Drivers with config.tbl
Adding/Removing Device Drivers with config.tbl

The config.tbl file controls the device drivers that are inserted into the kernel
at build time. Each driver has a one line entry in this file. Inserting the comment
character (#) in front of the line deactivates the given device driver. For example,
the code fragment below shows two lines from
$ENV_PREFIX/sys/bsp.<bsp_name>/config.tbl on a LynxOS x86 system:
# Primary ide controller
I:ide.cfg
This fragment indicates that the LynxOS kernel built with this config.tbl
contains a device driver for the secondary IDE controller. To remove this device
driver, modify the lines in config.tbl as shown below:
# Primary ide controller
#I:ide.cfg
Similarly to enable support for Intel PRO/100 NIC, uncomment the following line
from config.tbl as shown:
I:fxp.cfg
To reflect changes in config.tbl, the kernel must be rebuilt.
CAUTION! Whenever config.tbl is changed, the device node configuration for

the new kernel may also change.
Making a Personal Kernel Build Directory

When working on team projects, developers may need to maintain individual
kernel build environments. The $ENV_PREFIX/sys/bsp.<bsp_name>
directories were designed with this scenario in mind.
The $ENV_PREFIX/sys/bsp.<bsp_name> directories are position-
independent. That is, they can be copied to any location on the file system and then
used to build a local kernel (a.out) from the copy.
The Makefile in the bsp.<bsp_name> directory uses the environment variable
$ENV_PREFIX to find the library archives and object rules, but it is otherwise

ignorant of its location on the disk. The shell script SETUP.<shell> defines
$ENV_PREFIX when executed:
$ cp -r $ENV_PREFIX/sys/bsp.x86_pc /tmp/my_bsp
$ cd /tmp/my_bsp
$ touch config.tbl
$ make all
In this way, multiple developers can have multiple kernel build directories on a
given system, each with its own unique config.tbl, nodetab, and uparam.h
files.
Customizing from a Cross-Development Host

The LynxOS distribution for cross-development environments provides users with
two shell scripts, which define several key environment variables such as PATH and
ENV_PREFIX. These shell scripts, SETUP.bash and SETUP.csh, are located in
/usr/lynxos/<release>/<platform>, where <release> is the LynxOS
version number, and <platform> is x86 or ppc. One or the other of these
scripts, depending on the shell requirements of the developer, must always be
executed before developing applications with LynxOS tools.
The scripts are invoked using the following syntax (in the examples below, for
LynxOS Release 5.0, loaded onto an x86 development host):
• For the csh shell:
$ cd /usr/lynxos/5.0.0/<platform>
$ source SETUP.csh x86
• For the bash shell:
$ cd /usr/lynxos/5.0.0/<platform>
$ . SETUP.bash x86
All further examples assume that the user has already set up the development
environment with one of the above scripts.
Adding TCP/IP to a LynxOS Kernel

To add TCP/IP to a LynxOS kernel, perform the following steps:
1. Change directory to the BSP directory:

Customizing a Kernel for Performance
2. In LynxOS, TCP/IP support is enabled or disabled by default. To enable

TCP/IP, make sure that in the config.tbl file the I:hbtcpip.cfg
line is not commented out and the I:nullnux.cfg line is commented
out:
I:hbtcpip.cfg
#I:nullnux.cfg
NOTE: When the TCP/IP module (I:hbtcpip.cfg line) is disabled by

commenting it out, the I:nullnux.cfg line must be uncommented and
vice-versa.
3. Rebuild the kernel:

$ make all
Customizing a Kernel for Performance

The parameters defined in $ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h
tell the kernel how much space (dynamic memory) to set aside for various data
structures at run-time. Users can modify this file to increase (or decrease) the
default values.
Configurable Parameters in
/sys/bsp.<bsp_name>/uparam.h
Table 7-5 lists some of the more important configurable parameters in the binary
code written for a standard development LynxOS system installation in the
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h file. Other configurable
parameters are also contained in this file, and can be found by searching for the
character string #define.
The $ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h file can be viewed
using the more command or in a text editor such as vi.

Modification to the values of these parameters not only influences system

performance, but also increases or decreases the dynamic size of the kernel.
NOTE: Before changing $ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h,

read the comments in the files for any parameter that has been changed. Some
parameters depend on others. The value of
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h/LIM_NFILES, for example,
must be greater than or equal to the sum of all the file parameters, including
message queue, shared memory, and semaphore special files. Otherwise, there is
no room for these files, and the system does not allow them to be created or stored.
Parameter Default Values in

/sys/bsp.<bsp_name>/uparam.h
The configurable parameters and their default values in the
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h file are listed in the table
below:
Table 7-5: Default Values for /sys/bsp.<bsp_name>/uparam.h—System-wide Limits
Default
Parameter Name What the Parameter Defines
Value
MAXSYMLINKS Symbolic links in a path. 8

NBDEVS Dynamically-loaded block devices. 16
NCDEVS Dynamically-loaded character devices. 48
NDRIVS Dynamically-loaded drivers. 32
NEXTRA_CLOCK Number of extra clocks. 0
NEXTRA_CLOCKSRC Number of extra clock sources. 1
NUM_CPUS Number of CPUs to be utilized by LynxOS. 0
LIM_NPROC Processes. Note that for some platforms there might be an 128
architectural limit on this number. In the case in which
LIM_NPROC is greater than the architectural limit, the
latter takes effect.
LIM_NTHREADS User threads. 336
ISA_SAFE_DMA_PAGES Number of pages allocated for ISA device (within range 0
0x00000000 - 0x00FFFFFF)

Increasing Maximum Processes
Table 7-5: Default Values for /sys/bsp.<bsp_name>/uparam.h—System-wide Limits
Default
Parameter Name What the Parameter Defines
Value
NUMIOINTS Registerable interrupt vectors via iointset(); 80

combined number of interrupt vectors derived by combining
number of hardware vectors with software multiplexes.
System-wide.
SIGQUEUE_MAX Number of queued signals one thread can accumulate. 256
TOTAL_SDRAM_SIZE In order to decrease OS boot time, some BSPs do not 64 MB or
automatically detect the size of on-board RAM. This 128 MB
parameter hardcodes the RAM size for those BSPs.
QUANTUM Clock ticks until preemption. 25
USR_NFDS Open files per process. 128
Increasing Maximum Processes

To customize a LynxOS kernel to handle a greater number of processes, perform
the following steps:
1. Make a backup copy of uparam.h (to revert to the kernel’s original
settings) using the following command:
$ cp uparam.h uparam.h.old
2. Use a text editor, such as vi, to edit uparam.h.
3. Find the parameter LIM_NPROC, and increase its number as follows:
#define LIM_NPROC <xxx> /* max number of processes */
NOTE: The LIM_NPROC parameter is being increased to increase the maximum

number of processes. Here, <xxx> represents the LIM_NPROC number.
To activate the changes, rebuild the kernel, create a new KDI, and boot the target
system with the new KDI.

Customizing the Number of CPUs

In this section, the CPU term refers to individual CPU chips for single-core CPUs,
individual cores for multi-core CPUs, or individual logical CPUs for CPUs with
Hyper-Threading (or similar) technology. Each CPU is able to run one thread of
execution at a time. Therefore, a system with N CPUs is able to run N threads of
execution at a time.
The NUM_CPUS parameter defined in the
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h file controls the number of
CPUs utilized by LynxOS. If there is no NUM_CPUS parameter in uparam.h, the
BSP does not support Symmetric Multi-Processing and will always utilize only
one CPU.
This section describes the NUM_CPUS setting for the x86_pc BSP. For other BSPs,
refer to the comments in the BSP-specific uparam.h file, but the basic principles
are similar.
Table 7-6 lists the possible values for NUM_CPUS and provides their descriptions.
Table 7-6: The NUM_CPUS Settings
NUM_CPUS
Description
Value
0 Automatically detect the number of CPUs

-1 Trust the BIOS/firmware on CPU configuration
1 Force single-CPU mode
2 or greater Define the number of CPUs to be utilized
If the NUM_CPUS parameter is set to 0 (the default value), LynxOS will try to
determine the number of CPUs automatically and utilize all CPUs. This usually
works well enough for most configurations, but it may be undesired if the user
wants to do the following:
• Reduce boot time. Automatic CPU detection adds about a quarter of a
second to the boot time on the x86 platform. The user may prefer to
hardcode the number of CPUs in uparam.h to make the system boot
faster. Alternatively, setting NUM_CPUS to -1 will make LynxOS use
CPU configuration information provided by the BIOS. The BIOS passes
that information to the operating system via memory tables conforming
to either the MP Specification or the ACPI standard (in the latter case,

Customizing the Number of CPUs
ACPI support must also be enabled in the BSP's config.tbl file).

Make sure that the appropriate BIOS settings, if any, are enabled.
• Compare the system's performance in different CPU configurations with
everything else being the same. To do that, the user may set NUM_CPUS
to a value less than the actual number of CPUs in the system. Note that
LynxOS does not detect the exact CPU topology and will utilize CPUs in
the order of discovery, which is not defined and may very well be
random. For example, if the system has two dual-core CPU chips, and
NUM_CPUS is set to 2, it is not defined whether the two utilized CPU
cores will be on the same chip or not. Setting NUM_CPUS to 1 (single-CPU
mode) is somewhat special compared to other hardcoded CPU numbers.
In the single-CPU mode, LynxOS does not perform many time-
consuming operations necessary in a multi-CPU environment. Also a
number of data cache issues pertaining to such environments vanish. For
some workloads, such as IPC and networking, this may result in better
performance.
• Disable Hyper-Threading (or similar) technology. The user may want to
disable Hyper-Threading, because this technology is not deterministic
enough for certain real-time applications. Also, some applications may
run slower with Hyper-Threading enabled. The proper way to disable
Hyper-Threading is to disable it in the BIOS and set NUM_CPUS to -1.
Note that setting NUM_CPUS to 0 does not guarantee that Hyper-
Threading is disabled in LynxOS even if it is disabled in the BIOS. If
there is only one single-core CPU in the system, and it supports Hyper-
Threading, setting NUM_CPUS to 1 will disable Hyper-Threading.
The number of CPUs utilized by a running LynxOS system may be determined by
using the sysctl utility:
$ sysctl hw.ncpu
hw.ncpu: 2
$
In this example, LynxOS utilizes two CPUs.

Changing Kernel Size

Usually, users change the size of a kernel to decrease the amount of storage space it
needs and/or the amount of memory it needs for execution. This section shows the
components of the kernel that affect its size, both in terms of memory and storage.
There are four basic components that users can modify to change the size of the
LynxOS kernel:
• System parameters in
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h
• Functionality modules (TCP/IP, NFS, and so on)

• Device drivers
• Symbol table information
Of these, uparam.h is the only component that is dynamic - changes to
uparam.h affect the kernel size in memory. The other components mainly affect
the static size of the kernel - the amount of space it takes to store on a device.
However, if users reduce the static size of the kernel, they usually reduce some of
its dynamic size as well. The only exception is the symbol table information -
removing this only affects the static size of the kernel.
After determining the components to modify, users must make a new kernel to see
the size changes in effect. This process is similar to tuning a kernel for
performance.
Determining the Kernel Size

The following subsections detail how to experiment with changing a kernel and
determine its size.
Determining Kernel Disk Space Usage

An easy way to determine the how much total disk space the kernel is using, is
using the ls -l command, as shown below:
$ ls -l a.out
-rwxr-xr-x 1 root 1758122 Oct 29 12:01 a.out
The kernel in this example uses 1758122 bytes, or about 1716 KB of space.

Determining Kernel Memory Usage
The size command allows users to look closely at the sizes of the text, data,
and bss segments of the kernel, as illustrated by the command and output below:
$ size a.out
text data bss dec hex filename
1068263 182700 255616 1506579 16fd13 a.out
This utility reports the size (in bytes) of each segment and the sum of the segments.
The total size of the file a.out, in this example, is 1506579 bytes (or
0x16fd13).
In addition to the text and data segments, the kernel contains header and
symbol table information that take up additional space.
Determining Kernel Memory Usage

Determining kernel memory usage is more difficult than determining its static size.
Users can use the ps command to look at a currently running LynxOS kernel.
The following example shows how to use ps to look at a currently running
LynxOS kernel. On a LynxOS system, enter the following command:
$ ps -axonmT
This command displays all currently executing processes, including threads and
unattached processes, and reports the total free memory (both physical and virtual)
in kilobytes (KB) at the end of the listing:
pid text stk data dlim d% slim s% smem name
0 0 20 4 0 100 0 100 0(0) nullpr
1 62 36 18 16384 0 4096 9 30(7) /init
2 405 44 95 16384 0 4096 0 135(13) /bin/sh
13 124 44 57 16384 0 4096 0 55(8) /net/inetd
14 126 40 57 16384 0 4096 0 56(8) /net/rlogind
15 39 36 27 16384 0 4096 0 26(6) /bin/login
16 405 44 94 16384 0 4096 0 134(12) /bin/bash
19 61 40 67 16384 0 4096 0 42(11) /bin/ps
0 0 16 0 0 100 0 0 0(0) ATC
0 0 16 0 0 100 0 0 0(0) CALLOUT
0 0 16 0 0 100 0 0 0(0) bsd_netisr
0 0 16 0 0 100 0 0 0(0) fxp
0 0 32 0 0 100 0 0 0(0) USB CALLOUT
0 0 32 0 0 100 0 0 0(0) usb softintr thread
0 0 32 0 0 100 0 0 0(0) usb event thread
0 0 32 0 0 100 0 0 0(0) usb task thread
0 0 32 0 0 100 0 0 0(0) usb event thread
0 0 32 0 0 100 0 0 0(0) usb event thread
0 0 16 0 0 100 0 0 0(0) TX
0 0 16 0 0 100 0 0 0(0) RX
2042172K free physical memory, 2297K used (in this display)
To calculate the size of the kernel:

1. Add the amount of free physical memory (110492 KB) to the amount
used (1296 KB): 110492 + 1296 = 111788 KB.
2. Subtract this number from the total amount of memory (RAM) on the
LynxOS system.
The machine in this example has 128 MB of memory, which translates to
131072 KB: 131072 – 111788 = 19284 KB.
Reducing the Number of TCP/IP Buffers

Some LynxOS BSPs come with a large number of TCP/IP buffers configured by
default as required by Gigabit Ethernet drivers. If Gigabit Ethernet is not being
used, users may configure a smaller number of buffers and reduce the kernel
memory usage.
To reduce the number of TCP/IP buffers, perform the following steps:
1. Change directory to the BSP device info file directory:
$ cd $ENV_PREFIX/sys/devices.<bsp_name>
2. Use a text editor (such as vi) to modify the hbtcpip_info.c file as
shown below to reduce the number of MBUFs and CLUSTERs:
.
.
.
struct hbtcpip_info hbtcpip_info0 = {
4096, /* No. of MBUFs - Has to be a multiple of 4 */
1024, /* No. of CLUSTERs - 1/4-th MBUF value recommended */
256, /* Number of callouts/timeouts */
.
.
.
Change the values 4096 and 1024 to lower values (for example, 1024 and
256).
3. Rebuild the device info files:
$ make install
$ make all
5. Create a KDI with the new kernel and boot the system with the new KDI.

Removing Unused Device Drivers
Removing Unused Device Drivers

One way to change to the size of a kernel is to remove unused device drivers, as
described in the example below:
This example is based on a LynxOS x86 system that does not need TCP/IP
networking.
Before Beginning
1. Back up the /sys/bsp.x86_pc files and directories to /tmp/test
by entering the following commands:
$ cp -r $ENV_PREFIX/sys/bsp.x86_pc /tmp/test
2. Change to the /tmp/test directory.
$ cd /tmp/test
Modifying config.tbl
Use a text editor (such as vi) to modify /tmp/test/config.tbl as shown
below to comment out unnecessary drivers by adding a pound character (#) to the
beginning of the line:
#
# TCP/IP Support
#
#I:hbtcpip.cfg
I:nullnux.cfg
#***********************************************************************
Building the Newly Customized Kernel

Use the following procedure to build a new kernel:
1. Change the working directory to /tmp/test.
$ /tmp/test
2. Build a new LynxOS kernel by entering the following command:
$ make all
After building the new kernel, the make utility generates the file
/tmp/test/a.out.

3. Verify that the new kernel has been created by entering the following
command:
$ ls -l a.out
-rwxr-xr-x 1 root 828495 Oct 29 12:01 a.out
In this example, the size of the new kernel is smaller than the previous
kernel by about 360 KB, verifying that the new kernel has accepted the
configuration changes made earlier.
Loading the New Kernel

Create a KDI with the new kernel and boot the system with the new KDI.
Adding Functionality to a Kernel

Many LynxOS users need to develop device drivers that are specific to their target
hardware. LynxOS supports this development with the
$ENV_PREFIX/sys/bsp.<bsp_name>/Makefile file. In this Makefile, users
can see several Makefile environment variables that they can modify to explicitly
specify custom device drivers, patches, or other objects to include in the kernel.
Adding a Custom Device Driver

LynuxWorks recommends the following approach for adding a custom driver to a
LynxOS kernel. Substitute actual file and directory names where appropriate in the
example below.
1. Create a custom driver directory in /sys/drivers:
$ cd $ENV_PREFIX/sys/drivers
$ mkdir my_driver
2. Use an existing device driver Makefile as a template by entering the
following command:
$ cp null/Makefile my_driver
3. Modify the Makefile so that during a kernel build, the driver is compiled
into a unique archive:
FILES = <file1.x> <file2.x> <file3.x>
LIBRARY=mydrivers

Adding a Custom Device Driver
These lines instruct the Makefile to compile file*.c files, and to insert
the compiled .o files in $ENV_PREFIX/sys/lib/libmydrivers.a.
Users can look at the OBJ_RULES file in the /sys directory to
determine the substitutions that are appropriate for their compilation of
the .c files. For example, .x compiles an optimized ANSI .c file,
while .u.x does not optimize the .c file.
4. Build the driver library:
$ cd $ENV_PREFIX/sys/drivers/my_driver
$ make install
5. Modify the Makefile in /sys/bsp.<bsp_name> so that the archive for
the device driver is linked to the kernel.
OTHER=-lmydrivers
6. Add the configuration file my_driver.cfg for the driver in

/sys/cfg; see Writing Device Drivers for LynxOS for more information
about device configuration files.
7. Edit the $ENV_PREFIX/sys/bsp.<bsp_name>/config.tbl so that
the new driver is represented:
I:my_driver.cfg # <description>
NOTE: New drivers should always be added to the end of config.tbl so that the
major and minor numbers for existing device drivers remain the same:
8. Build the LynxOS kernel with the new device driver by entering the
following commands:
$ make all

Configurable Tick Timer

Users can configure the number of ticks per second of the system real-time clock.
The TICKSPERSEC configurable parameter in the
sys/bsp.<bsp_name>/uparam.h file defaults to 1000 ticks per second.
LynuxWorks recommends to use tick rates from the following range:
Table 7-7: Recommended Range for TICKSPERSEC
Minimum ticks per second Maximum ticks per second
100 (10ms between ticks) 10000 (100 us between ticks)
NOTE: The underlying hardware performance may impose a limitation on the clock
rate. The slower the system is, the larger percentage of CPU time it will spend
processing clock interrupts. For some slow systems, high clock rates may not be
achievable.

CHAPTER 8 Creating Kernel Downloadable
Images
LynxOS supports creating Kernel Downloadable Images (KDIs) with the

mkimage utility. KDIs combine the LynxOS kernel and its associated applications
into bootable images designed for easy downloading onto development targets.
Overview
Users can create application-ready embedded systems that include the
LynxOS kernel and customized application into bootable images, which can then
be implemented in one of the following ways:
• Burned into Flash
• Put onto distribution media (CD-ROM)
• Booted over a network
• Maintained on hard drives
A LynxOS kernel image is a special boot file that always contains a
LynxOS kernel binary and usually also contains a RAM-based root file system
(called a RAM disk) with minimal files for operating system functions and
applications.
mkimage—the LynxOS KDI Creation Utility

The mkimage utility creates a single file—a bootable KDI—with some or all of
the following LynxOS components:
• The LynxOS kernel
• A memory image of a RAM disk with a specified initial set of files

Chapter 8 - Creating Kernel Downloadable Images
• The text segments of applications loaded at initialization time

The mkimage utility creates the image with attributes that users set in a
specification file. By defining the fields in the specification file, users can create
customized images for their specific development targets. For more information on
specification files, see “Creating a Specification File” on page 64.
NOTE: See the mkimage.spec man page for an explanation of specification files.
mkimage Syntax and Features

The syntax for mkimage is as follows:
# mkimage <spec_file> <output_file>
NOTE: Additional options are available in the mkimage man page.
The mkimage utility lets users create bootable kernel downloadable images in
any directory, with any number of contained files.
LynxOS Kernel
Users must specify what kernel binary to use when building the KDI. Users are
most likely to create a custom kernel for use in their specific image. For example,
users may choose to remove any unused device drivers from the kernel to reduce
the size of the kernel and, as a result, of the final image.
(See Chapter 7, “Customizing the Default LynxOS Kernel Configuration” for more
information on creating custom kernels.)
To save space, mkimage does not expand the bss section of the kernel in the
image. The bss section is expanded and initialized to zeros by kernel code.
Typically, the starting execution address is 32 (0x20) bytes after the start of the
image in memory. The exact format of the image depends on the BSP.

Embedded File Systems
Embedded File Systems

Embedded file system images can be one of two types:
• An image that may be used as the root file system contained in, or
referenced by, the kernel image
• A standalone file system image that may be mounted as an additional file
system after LynxOS is up and running—The mkimage utility prepares
both standalone and kernel root file systems.
Embedded Root File Systems

Embedded root file systems can be one of the following three types:
• RAM-Based File System
The mkimage utility may be used to create a memory-based root file
system. LynxOS accesses this file system using its RAM disk driver. This
file system may physically reside in RAM, ROM or Flash memory,
depending on how the image is used and created for the target machine.
Depending on the set of utilities in the image, it may function as a
minimal application or as a complete LynxOS development system.
• Disk-Based File System
If the major and minor numbers of a disk drive attached to a target system
are specified, that drive may be used as the root file system for the
KDI. A disk-based root file system behaves identically to a kernel
root file system booted from disk.
• No File System
For kernels appropriately generated, the image does not contain or
reference a file system.
Embedded Standalone File System Images

An embedded standalone file system image is memory-based and may be accessed
through the LynxOS RAM disk driver. The file system image may reside in any
type of physical memory but is most likely to be in ROM or Flash memory. No
provision for moving the embedded file system image to RAM is provided by the
LynxOS kernel. Application text segments may or may not be resident as required
(see “Resident Text Segments” below).

Resident Text Segments

Applications may have resident (execute in place—XIP) text images in an
embedded memory-based file system. In a normal file system, the text segment of
an application is copied from the file system to RAM for execution. In a memory-
based file system, the text segment is copied from the memory-resident file system
to memory. Resident text applications do not require this copying process, which,
in turn, reduces run-time RAM memory requirements. The considerations that
should be taken into account when deciding to use resident text are as follows:
• The type of memory the resident text is in
• Required execution speed
• RAM constraints
• Type of embedded file system
NOTE: Be aware that specifying text=ram for a root file system image that
normally resides in some type of ROM copies all of the application’s resident text
in the image to RAM during kernel initialization.
When the execution speed of the application is most important, the text of the
image should reside in RAM because, in general, any type of ROM is slower than
RAM. There are several ways to accomplish this, depending on how the KDI or
File System Image (FSI) is specified and on the type of memory the image resides
in.
When the application is in the root FSI and the KDI is in RAM, resident text
should be used to ensure optimal execution speed and RAM conservation.
When the application is in the root FSI and the KDI is in some sort of ROM, the
text may or may not need to be resident. When the text is specified as resident and
text=ram is also specified, the resident text of the application (and all other
resident text applications) is copied to RAM by the kernel during kernel
initialization. When the text is not specified resident, the kernel loads the
applications text to RAM from the file system at execution, identically to the
application text residing on a disk drive. Since there is no provision to move
resident text segments to RAM in a standalone FSI, a nonresident text segment is
the only way to have the application run out of RAM from a standalone FSI
residing in some sort of ROM.
When the root or standalone FSI resides in ROM and execution speed is a
priority, leaving the application text segments in the nonresident files system

Creating a KDI Image
conserves the greatest amount of memory. This causes the kernel to load the text
segments on demand into RAM from the FSI. Alternatively, when the root FSI
resides in RAM, using resident text for applications conserves the greatest amount
of memory.
Creating a KDI Image
Procedure Overview
The same basic steps are used to create images for the entire range of boot
applications, from network booting to ROM booting:
• Configure a LynxOS kernel with the desired functionality.
• Create a specification file for mkimage that defines the LynxOS kernel
to use and any applications to include.
• Run mkimage.
• Test the image.
• Put the image into the target environment.
For information on network booting the image, please refer to your LynxOS Board
Support Guide.
The following steps detail creating a KDI. These steps are also explained in the
subsections that follow:
1. If you want to avoid changing the original files, create a copy of
/sys/bsp.<bsp_name> by entering the following commands:
$ cp -r $ENV_PREFIX/sys/bsp.<bsp_name> \
<new_BSP_dir>
where <bsp_name> is the name of the target BSP and
<new_BSP_dir> is the name of a new directory to create a customized
kernel in.
2. Change to the (new) BSP directory.
3. Make sure the RAM disk driver is enabled in config.tbl. It is enabled
by default.
4. Make any other modifications to files such as uparam.h and
Makefile.

5. Create a new kernel with make all.

6. Create a specification file with desired attributes.
7. Run mkimage.
NOTE: When developing application on a LynxOS cross-development host, it is

necessary to use $ENV_PREFIX/<pathname> where absolute paths are shown in
this chapter.
Enabling the RAM Disk Driver

To enable the RAM disk driver, users must uncomment (by removing the # sign)
the line I:ramdisk.cfg in the config.tbl file.
Modifying Kernel Parameters

One way to reduce the size of a kernel is to remove all superfluous drivers. See
Chapter 7, “Customizing the Default LynxOS Kernel Configuration” for examples.
Creating a Specification File

Some important attributes of the specification file are as follows:
Table 8-1: Specification File Attributes
Attribute Description
target=[x86|ppc] The target system.

osstrip=[local|all|none] Causes local symbol definitions to be stripped
from the kernel text file.
ostext=[ram|rom] Designates where the kernel resides in the
running system.
kernel=path The path of the LynxOS kernel to be used in the
image.
nodetab=path The device node table corresponding to the
kernel
free= Designates the number of free blocks on the
embedded root file system.

Creating a Specification File
Table 8-1: Specification File Attributes (Continued)
Attribute Description
inodes= Designates the number of free inodes on the

embedded root file system.
root=[ram|rom] Specifies that the root file system is either
resident in RAM, resident in ROM, mounted
from the device, or that there is no file system.
strip=[true|false] Designates whether or not the application files
on the embedded root file system are to have
symbols stripped.
text=[ram|rom] Designates that the resident application
programs on the embedded root file system
will be in ROM or moved to RAM.
resident=[true|false] Designates whether or not the application
programs on the embedded root file system
are to be resident in memory.
directory= A directory on the embedded root file system.
file= A file on the embedded root file system.
source= Designates a fully qualified pathname to a
source file to be copied into the embedded root
file system as the file specified in the file=.
owner= Designates the numeric owner ID of the target
file.
group= Designates the numeric group ID of the target
file.
mode= Designates the permissions for the target file.
symlink <pathname1> <pathname2> Designates a symbolic link of <pathname1> to
<pathname2>.

Testing Kernel Images

For target hardware for which the LynxOS preboot hard disk boot loader utility
is supported, users can use it to directly test the kernel images made with mkimage
(see the preboot man page for the specific commands used on different
platforms). For example, to test the kernel image /image1 located on partition A
of the SATA disk on a LynxOS x86 machine, perform the following steps:
1. Reboot the machine.
2. At the preboot prompt (Command?), enter the following command:
Command? b sata.0a /image1
Booting KDIs
Booting Images over a Network

To network boot LynxOS (also called to netboot), the image file is stored on a
remote server and copied over the network into the RAM of a remote node by the
firmware-resident TFTP boot code. The node could be diskless.
Because everything is in RAM, the boot code gives control to the loaded operating
system, which in turn, configures the attached RAM disk as its root file system.
In this case, because all the executables are in RAM, it is useful if they are
executed directly without being copied again into RAM. Thus, the TEXT
segments of the executables are loaded as part of system initialization at boot time,
rather than on demand from the root file system.

Sample KDIs
In the remote boot configuration, the RAM memory map is sequential, as shown in
the figure below:
INT Vectors (optional)
OS TEXT Segment
OS DATA Segment
OS bss Segment
OS Symbols
RAM Disk File System
Application TEXT Segments
Figure 8-1: Example RAM Memory Map
Sample KDIs
Each LynxOS BSP provides a sample net-bootable KDI containing a RAM-disk
root file system with a small set of utilities. When started, the sample KDI
displays a shell prompt on the default console (what device is used for the default
console is specific to the particular BSP). To create a sample KDI, enter the
following commands:
$ make netkdi
This creates a sample KDI named net.img.
KDI Build Templates

The $ENV_PREFIX/usr/demo directory allows users to easily build their own
KDIs for execution on target hardware. A KDI build template essentially consists
of all the binary and source files required to develop a custom application for the
user’s target system using LynxOS.
NOTE: The KDI build templates are automatically installed as a part of the default
installation.

The sections that follow demonstrate how to set up a KDI project area, build a
KDI, and download and execute it on a target. Because the project scripts are
written in Bourne Shell, these build steps can be followed on any cross-
development system.
Template Conceptual Overview

LynuxWorks provides KDI directories to give users a set of templates from which
they can jump-start their own development of KDIs. The scripts automate the
process of creating a project directory, copying a kernel build directory, installing
the appropriate device drivers, building the kernel, selecting the appropriate files
from the LynxOS distribution, and generating a KDI.
Included KDI Build Templates

The following table describes the KDIs that are provided with LynxOS.
Table 8-2: List of KDI Templates
Build Template Summary
developer Contains development and networking utilities that provide a minimal configuration
for development. Includes the following utilities:
•mkpart and mkfs—Disk formatting utilities
•gnutar—gnutar and gnuzip utilities
•shell—Minimal shell configuration
•rcp—RCP (remote copy) utility
•ftp—FTP (file transfer protocol) utility
•mount— mount utility
hello Simple hello world demo

KDI Directory Structure
Table 8-2: List of KDI Templates (Continued)
Build Template Summary
linuxabi This KDI demonstrates ABI compatibility in LynxOS. The Linux ABI compatibility
(x86 only) layer allows application programs that are created under other environment (Red
Hat Linux in this demo) to run unchanged in the LynxOS environment. The demo
provides two KDIs:
•A service KDI to help preparing the file system on target’s hard disk
•A linuxabi KDI to provide Linux ABI support
xfree86 This KDI demonstrates an X window environment with basic X functionalities on
(x86 only) LynxOS. The demo provides the following:
•XFree86 X server
•XFree86 twm or LessTif mwm window manager
•Some simple XFree86 X applications, such as xterm, xcalc, xclock,
oclock, and xeyes
KDI Directory Structure

The demo KDI directory includes the following files and directories:
Table 8-3: KDI Directory Structure
KDI Directory/File Description
Makefile This is the top-level Makefile.

PROJECT.sh This Bourne Shell script sets up a custom KDI build
environment.
README This file describes contents of the kdi directory.
common This directory contains shared source code, binaries and
scripts.
bsp This directory contains single port files for target
hardware boards.
developer This directory contains configuration files and scripts to build
the developer demo KDI.
hello This directory contains configuration files and scripts to build
the hello demo KDI.

Table 8-3: KDI Directory Structure (Continued)
KDI Directory/File Description
linuxabi This directory contains configuration files and scripts to build

(x86 only) the linuxabi demo KDI.
xfree86 This directory contains configuration files and scripts to build
(x86 only) the xfree86 demo KDI.
Restrictions
This demonstration harness assumes that a single user is building the KDI. It also
assumes that the building of demo KDIs is done one at a time, since all demo KDIs
share the same BSP directory where kernels are built; therefore, two KDI
directories cannot be built in parallel.
Getting Started
A shell script, PROJECT.sh, is provided to automate the setup process. Before
running this script, users must have already installed LynxOS from the distribution
CD-ROMs onto the system’s hard disk and have sourced the SETUP.bash or
SETUP.csh scripts provided.
These scripts set up the PATH environment variable and also set ENV_PREFIX to
point to the distribution directory. ENV_PREFIX must be set correctly for
PROJECT.sh to work.
To set up ENV_PREFIX, source the SETUP.bash or SETUP.csh scripts

provided in the LynxOS release directory.
To verify that ENV_PREFIX is set correctly, enter the following command, which
lists the LynxOS distribution:
$ ls $ENV_PREFIX
If ENV_PREFIX is set correctly, then execute the PROJECT.sh script by entering
the following command:
$ cd $ENV_PREFIX/usr/demo
$ . ./PROJECT.sh

Building KDIs
The following screen output is displayed:

=======================================================
| Project set up script |
| |
| This script will create a customized directory for |
| building and experimenting with Kernel Downloadable |
| Images (KDIs.) |
=======================================================
Note: 10MB of available disk space is needed for minimal project
directory. 30MB is recommended.
Project directory location? [/tmp/newproj]
Enter a location on disk where the user has write permission (/tmp/newproj is
the default) with at least 10 MB of free space available (30 MB is recommended).
The following output is displayed:
The following BSPs are supported:
PPC [radppc7d, cwdy4_183]
x86 [x86_pc]
Which BSP should we use? [x86_pc]
Enter network name/IP address for target now? [n]
If a machine name and an IP address for the target board has been selected, enter y.
The PROJECT.sh script goes through the process of modifying the rc.network
file for the specified target. If n is entered, then the rc.network file that gets
configured into the system’s KDIs interactively prompts the user for the machine
name and IP address at boot-time as follows:
What is the network interface of the target board? [em0]
What is IP address of the target board? [1.1.1.1]
Once all questions have been answered, PROJECT.sh proceeds to set up the
customized KDI build environment, copying the appropriate files.
Building KDIs
To begin building KDI demos, change the working directory to
/tmp/newproj/hello, and issue a make all command; the following steps
are executed:
#########
# Step 1a. Modify config.tbl
#########
This step creates a local copy of config.tbl, which is used by the kernel
Makefile to configure device drivers as either in or out. This config.tbl file is
copied to the local Board Support Package (BSP) directory (where the kernel is
linked) each time the user issues a make command in this
/tmp/newproj/hello directory.
#########
# Step 1b. Modify uparam.h

#########
This step creates a local copy of the uparam.h header file. This file is used to
specify the size of user-modifiable kernel data structures and resources.
Like config.tbl, the uparam.h file is copied to the local BSP build directory
each time a make command is issued in /tmp/newproj/hello.
#########
# Step 2: Perform any local build actions defined in desc.<bsp_name>.sh
#########
This is a hook that allows a KDI build directory to do any special local processing.
Look at the desc.* file for details.
#########
# Step 3: Make kernel
#########
This step changes directory to the ./bsp.* directory, and makes the kernel,
using the config.tbl and uparam.h files from the KDI build directory.
#########
# Step 4: Build KDI
#########
This step is run from within the KDI build directory. The mkimage tool is
invoked using the KDI mkimage specification file to pull together the appropriate
kernel components and applications.
#########
# Step 5: Build Complete
#########
Look at hello.kdi in /tmp/newproj. The following output is displayed:

-rwxr-xr-x 1 int 774144 May 11 19:38 /tmp/newproj/hello.kdi
The KDI can now be downloaded and executed on the target. For more information
on demo KDIs and loading KDI images onto the target, see the appropriate
LynxOS Board Support Guide.
Example—Building, Booting, and Using the developer KDI

The developer KDI includes development and networking components that
provide a development environment on a target board. This section describes how

Configuring the developer KDI
to create, boot, and use the developer KDI. This example uses the following
configurations:
Parameter Host Target
Platform Red Hat Enterprise Linux 4.0 or x86

Red Hat Enterprise Linux 5.1
LynxOS 5.0 Cross-Development
x86
Hostname linuxcdk x86-1
IP Address 192.1.1.1 192.1.1.2
Ethernet Address Not needed. 08:00:3E:23:8C:BD
Configuring the developer KDI

The default configuration of the developer KDI contains many utilities that
provides a wide range of functionality for a variety of development tasks. The
default configuration of the developer KDI can change by editing the
developer.spec file to add or remove functionality in the KDI.
Removing Unnecessary Components

The size of the developer KDI demo may be too large for some systems. The
default configuration is close to 10 MB. Unnecessary components can be removed
from the default KDI image by commenting out the lines in developer.spec
and rebuilding the kernel.
Enabling Required Components

Several components are not included in the default KDI. To enable the following
components, uncomment the required lines in the developer.spec file:
• Linux ABI Compatibility Layer (multiple files)
Check the developer.spec file and uncomment any files that are required by
these utilities to enable them in the developer KDI.

Rebuilding the KDI

After editing the developer.spec file, rebuild the kernel.
# make all

CHAPTER 9 Linux ABI Compatibility
The Linux ABI (Application Binary Interface) compatibility feature of

LynxOS allows Linux binary applications to run under LynxOS. This chapter
provides a detailed overview of the Linux ABI feature.
Overview
LynxOS supports executing dynamically-linked Linux binary applications on
LynxOS systems as if they were native LynxOS applications. There is no need to
rebuild Linux applications with LynxOS tools, or even access the source code.
Linux application binaries can be installed and executed on a LynxOS machine in
the same manner as they are installed and executed on a Linux system. The Linux
ABI feature adds a new level of flexibility by allowing users to use both Linux and
LynxOS binaries in parallel on a single LynxOS system.
Linux ABI compatibility is made possible by adding a Linux ABI Layer that
includes Linux libraries. “Native” LynxOS applications (applications built for
LynxOS) are unaffected by the addition of the Linux ABI Layer.
LynuxWorks provides a more comprehensive set of standard Linux shared libraries
(<media_num>.linuxabi.tar.gz). See later sections in this chapter for more
details on installing these libraries.
NOTE: Because the Linux ABI X11 libraries and the XFree86 and LessTif shared
libraries have the same names and are installed in the same directory,
/usr/X11R6/lib, care should be taken not to overwrite any libraries
inadvertently. For more details, please see Chapter 10, “XFree86 and LessTif.”

Chapter 9 - Linux ABI Compatibility
Linux ABI Layer

This section provides a brief overview of the Linux ABI software layer. The
following diagram shows how a Linux binary runs on LynxOS under the Linux
ABI Layer:
Linux LynxOS
dynamically-linked dynamically-linked
applications applications
link and
execute dynamic dynamic
links links
ld.so
dynamic Linux ABI LynxOS “native”
linker library libraries
libc libc ...

...
exec()
system
call
run-time run-time
system calls system calls
user space
kernel
LynxOS kernel
Figure 9-1: Linux ABI Software Layer
A dynamically-linked Linux application relies on the ld.so.1 dynamic linker

and loader to complete the process of linking all necessary references to shareable
objects before the application is executed.
Linux application binaries are linked by ld.so.1 with the shared libraries that
compose the Linux ABI Layer. This Linux ABI layer translates Linux application
shared object interface calls into calls that are binary-compatible with LynxOS
kernel interfaces. Typically, implementation of standard interfaces are similar
enough between Linux and LynxOS that only a simple translation (or none at all) is
required before a call from a Linux application can go into the LynxOS kernel.

Interoperability with LynxOS Native Applications
Interoperability with LynxOS Native Applications

The Linux ABI Layer relies on the LynxOS ld.so.1 dynamic linker to resolve
Linux application calls into shared objects using an appropriate set of Linux shared
libraries. Native LynxOS applications are not affected by the Linux ABI feature in
any way.
Linux ABI Shared Libraries

The following table shows the shared libraries included in the Linux ABI Layer.
The libraries are located in the same directories as they are on Linux. This allows
the LynxOS ld.so.1 dynamic linker and loader to link the Linux binary with the
Linux ABI shared libraries.
Table 9-1: Linux ABI Shared Libraries
x86 Shared Libraries

lib
lib/i686 -> tls
lib/ld-2.3.3.so -> ../usr/lib/ld.so.1
lib/ld-linux.so.2 -> ../usr/lib/ld.so.1
lib/libacl.so.1 -> libacl.so.1.0.3
lib/libacl.so.1.0.3
lib/libattr.so.1 -> libattr.so.1.0.1
lib/libattr.so.1.0.1
lib/libc-2.3.3.so
lib/libcrypt-2.3.2.so
lib/libcrypt.so.1 -> libcrypt-2.3.2.so
lib/libc.so.6 -> libc-2.3.3.so
lib/libdl-2.3.2.so
lib/libdl.so.2 -> libdl-2.3.2.so
lib/libgcc_s-3.2.3-20040701.so.1
lib/libgcc_s.so.1 -> libgcc_s-3.2.3-20040701.so.1
lib/liblynxpthread.so
lib/libm-2.3.3.so
lib/libm.so.6 -> libm-2.3.3.so
lib/libnsl-2.3.2.so
lib/libnsl.so.1 -> libnsl-2.3.2.so
lib/libnss_dns-2.3.2.so
lib/libnss_dns.so.2 -> libnss_dns-2.3.2.so
lib/libnss_files-2.3.2.so
lib/libnss_files.so.2 -> libnss_files-2.3.2.so
lib/libpcre.so.0 -> libpcre.so.0.0.1
lib/libpcre.so.0.0.1
lib/libproc.so.2.0.17
lib/libpthread-0.10.so
lib/libpthread.so.0 -> libpthread-0.10.so
lib/libresolv-2.3.2.so
lib/libresolv.so.2 -> libresolv-2.3.2.so
lib/librt-2.3.3.so
lib/librt.so.1 -> librt-2.3.3.so
lib/libSegFault.so

Table 9-1: Linux ABI Shared Libraries (Continued)

lib/libtermcap.so.2 -> libtermcap.so.2.0.8
lib/libtermcap.so.2.0.8
lib/libutil-2.3.3.so
lib/libutil.so.1 -> libutil-2.3.3.so
lib/tls/
lib/tls/libc-2.3.3.so -> ../libc-2.3.3.so
lib/tls/libc.so.6 -> libc-2.3.3.so
lib/tls/libm-2.3.3.so -> ../libm-2.3.3.so
lib/tls/libm.so.6 -> libm-2.3.3.so
lib/tls/libpthread-0.60.so -> ../libpthread-0.10.so
lib/tls/libpthread.so.0 -> libpthread-0.60.so
lib/tls/librt-2.3.3.so -> ../librt-2.3.3.so
lib/tls/librt.so.1 -> librt-2.3.3.so
usr/X11R6/
usr/X11R6/lib
usr/X11R6/lib/libGL.so.1 -> libGL.so.1.2
usr/X11R6/lib/libGL.so.1.2
usr/X11R6/lib/libGLU.so.1 -> libGLU.so.1.3
usr/X11R6/lib/libGLU.so.1.3
usr/X11R6/lib/libICE.so.6 -> libICE.so.6.3
usr/X11R6/lib/libICE.so.6.3
usr/X11R6/lib/libSM.so.6 -> libSM.so.6.0
usr/X11R6/lib/libSM.so.6.0
usr/X11R6/lib/libX11.so.6 -> libX11.so.6.2
usr/X11R6/lib/libX11.so.6.2
usr/X11R6/lib/libXaw.so.7 -> libXaw.so.7.0
usr/X11R6/lib/libXaw.so.7.0
usr/X11R6/lib/libXext.so.6 -> libXext.so.6.4
usr/X11R6/lib/libXext.so.6.4
usr/X11R6/lib/libXft.so.2 -> libXft.so.2.1
usr/X11R6/lib/libXft.so.2.1
usr/X11R6/lib/libXmu.so.6 -> libXmu.so.6.2
usr/X11R6/lib/libXmu.so.6.2
usr/X11R6/lib/libXmuu.so.1 -> libXmuu.so.1.0
usr/X11R6/lib/libXmuu.so.1.0
usr/X11R6/lib/libXpm.so.4 -> libXpm.so.4.11
usr/X11R6/lib/libXpm.so.4.11
usr/X11R6/lib/libXrender.so.1 -> libXrender.so.1.2.2
usr/X11R6/lib/libXrender.so.1.2.2
usr/X11R6/lib/libXt.so.6 -> libXt.so.6.0
usr/X11R6/lib/libXt.so.6.0
usr/X11R6/lib/libXv.so.1 -> libXv.so.1.0
usr/X11R6/lib/libXv.so.1.0
usr/X11R6/lib/X11/
usr/X11R6/lib/X11/XkeysymDB
usr/X11R6/lib/X11/locale/
usr/X11R6/lib/X11/locale/compose.dir
usr/X11R6/lib/X11/locale/locale.alias
usr/X11R6/lib/X11/locale/locale.dir
usr/lib/
usr/lib/libbz2.so.1 -> libbz2.so.1.0.2
usr/lib/libbz2.so.1.0.2
usr/lib/libexpat.so.0 -> libexpat.so.0.4.0
usr/lib/libexpat.so.0.4.0
usr/lib/libfontconfig.so.1 -> libfontconfig.so.1.0.4
usr/lib/libfontconfig.so.1.0.4
usr/lib/libfreetype.so.6 -> libfreetype.so.6.3.3

Adding Linux Shared Libraries to LynxOS
Table 9-1: Linux ABI Shared Libraries (Continued)

usr/lib/libfreetype.so.6.3.3
usr/lib/libGL.so.1 -> ../../usr/X11R6/lib/libGL.so.1
usr/lib/libGLU.so.1 -> ../../usr/X11R6/lib/libGLU.so.1
usr/lib/libncurses.so.5 -> libncurses.so.5.3
usr/lib/libncurses.so.5.3
usr/lib/libnss_dns.so -> ../../lib/libnss_dns.so.2
usr/lib/libnss_files.so -> ../../lib/libnss_files.so.2
usr/lib/libreadline.so.4 -> libreadline.so.4.3
usr/lib/libreadline.so.4.3
usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.3
usr/lib/libstdc++.so.5.0.3
usr/lib/libutempter.so.0 -> libutempter.so.0.5.5
usr/lib/libutempter.so.0.5.5
usr/lib/libz.so.1 -> libz.so.1.1.4
usr/lib/libz.so.1.1.4
Adding Linux Shared Libraries to LynxOS

Additional shared libraries not included in the LynxOS Linux ABI distribution
may be required in order to run certain Linux applications. For instance, the PERL
library extensions are needed to run the Linux-built perl binary on LynxOS.
Such additional libraries must be copied by the user from a Linux system and
installed in the appropriate directory on LynxOS. The Linux shared libraries do not
need to be rebuilt.
Determining Linux Application Library Dependencies

The shared libraries required by a particular Linux application and the directories
in which these shared libraries should be located (on the target system) can be
viewed with the ldd command on a Linux system. For example, the Linux ls
command requires the following libraries:
# ldd -d /bin/ls
libacl.so.1 => /lib/libacl.so.1 (0x00519000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x00a31000)
libc.so.6 => /lib/tls/libc.so.6 (0x00111000)
libattr.so.1 => /lib/libattr.so.1 (0x00635000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00896000)
# ls -l /lib/libacl.so.1 /lib/libtermcap.so.2
lrwxrwxrwx 1 root root 15 Feb 27 2006 /lib/libacl.so.1 -
> libacl.so.1.0.3

lrwxrwxrwx 1 root root 19 Feb 27 2006 /lib/libtermcap.so.2

-> libtermcap.so.2.0.8
NOTE: Some applications open shared objects using the dlopen() interface. Such
shared objects will not be listed by ldd. There is no means to determine such
hidden requirements; fortunately, most applications will fail in this case with some
meaningful diagnostic messages.
Updating Linux ABI Layer Libraries

Linux shared libraries can easily be updated to accommodate the needs of
particular Linux applications. New libraries can easily be added to the system
simply by copying them from Linux to the appropriate directories on a
LynxOS system. Updated versions of shared libraries can also be added to the
system by copying over the current shared library.
However, it is important to note that users should copy over the actual reference
file, and not symbolic links to the reference file. For example, users should not
copy over the file libncurses.so.5.2 and rename it libncurses.so.5. The
Linux convention is to create a symbolic link libncurses.so.5 to the updated
library libncurses.so.5.2. This allows any application that calls
libncurses.so.5 to access the updated shared libraries.
# cp <path>libncurses.so.5.2 /usr/lib
# cd /usr/lib
# ln -s libncurses.so.5.2 libncurses.so.5
# ls -l /usr/lib/libncurses.so.5*
total 509
lrwxrwxrwx 1 root 17 Feb 22 20:00 libncurses.so.5@ -> libncurses.so.5.2
-rwxr-xr-x 1 root 257524 Feb 19 18:05 libncurses.so.5.2*
Linux ABI Shared Libraries Not To Be Overwritten

User should not overwrite the following shared libraries installed from the Linux
ABI distribution:
• /lib/libpthread-0.10.so
• /lib/librt-2.3.3.so
• /lib/libc-2.3.3.so
• /lib/libutil-2.3.3.so
• /lib/libm-2.3.3.so

Specifying Linux ABI Shared Library Paths
• /lib/libSegFault.so
• /lib/ld*
These are Linux ABI-specific shared libraries that have the same names as Linux
shared libraries. These Linux ABI files are vital for the Linux ABI feature to
function. If these Linux ABI files are accidentally replaced by the Linux-based
shared libraries, the Linux ABI environment will not function.
Specifying Linux ABI Shared Library Paths

The LD_LIBRARY_PATH environment variable specifies a search path for ELF
shared libraries used by the ld.so.1 dynamic linker. To ensure that ld.so.1
locates all Linux ABI libraries required for a particular Linux application,
LD_LIBRARY_PATH must include the path names to all the locations (directories)
where respective Linux ABI libraries are located. LD_LIBRARY_PATH must be set
up and exported before a Linux application can be executed.
NOTE: By default, ld.so.1 searches the Linux paths to shared libraries included
in Linux ABI. LD_LIBRARY_PATH should be set only if the libraries are put in a
nondefault location.
NOTE: As defined by the ELF specification, if an application has the S-ISUID or

S-ISGID bits set in its protection mode, the ld.so.1 dynamic linker ignores the
LD_LIBRARY_PATH environment variable. To run such applications, the S-bits
must be removed from the protection mode and the application must be run from a
root (superuser) login.

Additional Features and Functions of Linux ABI

This section discusses additional features and functions of the Linux ABI
Compatibility Layer.
Linux Reference Distribution

The term “Linux Reference Distribution” is used to identify a particular version of
Linux that is compatible with the Linux ABI Layer on LynxOS. The Linux
Reference Distribution is composed of specific versions of these components:
• Linux kernel
• Linux glibc library
The Linux Reference Distribution is used to validate and test Linux ABI
Compatibility. Applications built on a supported version of the Linux Reference
Distribution are supported. As of this printing, Linux applications built on the
following Linux Reference Distribution are supported:
• Red Hat Enterprise Linux 3 (kernel 2.4.21-37, glibc 2.3.2)
Refer to the LynxOS Release Notes for updates or changes to the supported Linux
Reference Distribution.
Support for Dynamically Linked Applications

The Linux ABI implementation relies on the dynamic linker (ld.so.1) to resolve
calls made by Linux binaries into the shared libraries that comprise the Linux ABI
library. Such resolution is performed at run-time, when an application is loaded
and linked by ld.so.1.
NOTE: Execution of statically linked Linux binaries is not supported by

LynxOS. This, however, is a minor limitation, because most Linux binaries are
dynamically linked. Unless explicitly specified via a special option to ld during
compilation, all Linux binaries require further linking at run time by ld.so.1.
Support for Versioned Symbols

Linux binaries built on earlier releases of a supported Linux distribution should
function when run on LynxOS. For example, if Red Hat Linux 7.1 is the supported
Linux reference distribution, applications built on Red Hat Linux 6.x will run on

/proc File System Support
LynxOS. This is because the LynxOS ld.so.1 dynamic linker supports

resolution of versioned symbols in a shared library.
The Linux ABI libraries (such as the libc library) contain multiple, versioned
definitions of an interface entry point. These multiple definitions provide backward
binary compatibility for earlier releases of Linux. A defined version of an interface
corresponds to a particular version of the library, and thus to a particular release of
Linux. When ld.so.1 resolves links into a library, the version information is
available with each unresolved symbol. This allows ld.so.1 to determine the
version of a symbol that the application requires. By linking into an appropriate
version of symbols, ld.so.1 ensures that there are no version-dependent
discrepancies between the definition of the interfaces and the shared libraries.
/proc File System Support

Certain Linux applications need to access the /proc file system provided on
Linux.
To enable running of these applications, LynxOS provides its own implementation
of the /proc file system that provides a subset of functionality provided by
Linux.
Before such applications can run, the /proc file system should be mounted on
LynxOS as follows:
# mount /dev/procfs /proc
The following table provides a list of /proc items supported by LynxOS.
Table 9-2: LynxOS /proc Items
The /proc Item Description
cpuinfo CPU information.

devices The list of character and block devices
is printed along with their assigned
device major numbers.
filesystems The list of the supported file system
types is printed.
meminfo Memory statistic.

Table 9-2: LynxOS /proc Items (Continued)
mounts Currently mounted file systems are

reported: device, mount point, and
mount options.
uptime The system uptime and idle time, in
seconds. The uptime is the time since
the system startup. The idle time is the
time spent in the thread 0 (nullpr).
version The OS version.
sys/kernel/ngroups_max The maximum allowed number of
supplementary group IDs per process
is reported.
sys/kernel/osrelease The release of the operating system is
reported.
sys/kernel/pid_max The size of the process table is
reported (total, for all VMs).
sys/kernel/version The build version of the operating
system is reported.
net/dev Network statistics are reported for
each network interface in the system:
number of bytes/packets sent and
received, packets dropped, multicast
packets, and so on.
self A symbolic link to the current process
directory with per-process entries.
<pid>/cmdline The program executed by the target
process.
<pid>/cwd The symlink to the target process’s
working directory.
<pid>/maps The map of target process’s memory:
text, data, bss, stack, and shared
memory segments.

Exceptions and Limitations
Table 9-2: LynxOS /proc Items (Continued)
<pid>/root The symlink to the target process’s

root.
<pid>/status The process name, state, PID, PPID,
UID/GID, memory statistics, signals
state, supplementary groups, and file
descriptor table size.
<pid>/statm The target process’s memory statistics.
<pid>/stat The same statistics as for the
<pid>/status.
threads/<tid>/attr The state of target thread including
thread’s detach state, scheduling
policy and parameters, stack address,
and size.
(this item is not present on Linux and
provided as LynxOS extension).
Exceptions and Limitations

Certain Linux binaries are not supported by the Linux ABI Layer. The following
table provides a list of features that are not supported with the Linux ABI Layer.
Table 9-3: Exceptions and Limitations
Exception Comments
Statically linked applications Linux ABI Layer supports execution of

dynamically linked Linux binaries only.
Applications built in a Linux Linux ABI libraries contain only version of
context later than the Linux symbols for the current reference context, and
reference context previous versions of the reference context.

Table 9-3: Exceptions and Limitations (Continued)
Exception Comments
Applications that make Linux ABI Layer relies on the ABI libraries to
direct calls into the kernel translate calls between Linux applications and the
LynxOS kernel.
Applications that uses a An example of this type of an exception is an
feature of the Linux kernel application that uses the /proc file system
not available in the entries not supported by LynxOS.
LynxOS kernel
Extracting RPMs with rpm2cpio

Linux binaries are sometimes distributed as RPM files. Because LynxOS does not
support RPM, users must manually extract the contents of the RPM file on the
Linux system. The Linux utility rpm2cpio extracts the contents of the RPM file,
which can then be piped to cpio:
# rpm2cpio <rpm_filename> | cpio -ivd
For more information on using rpm2cpio and cpio, see their respective man
pages.
Running Applications on Linux ABI

To run Linux applications on Linux ABI for LynxOS, perform the following steps:
1. On LynxOS cross development host, edit the
$ENV_PREFIX/sys/bsp.<bsp_name>/uparam.h file make sure that
it contains the following lines:
LIM_NPROC 200
USR_NFDS 1024
LIM_NTHREADS 100
where <bsp_name> is x86_pc.

2. On LynxOS cross development host, edit the
$ENV_PREFIX/etc/starttab file as follows:
# Data, stack, and core file limits (in Kbytes)
65536
2048
32768

Running Applications on Linux ABI
3. Rebuild the LynxOS kernel on the LynxOS cross development host and
reboot the target using a KDI with the new kernel and the root file system
located on the target's hard disk.
4. Unpack the Linux ABI tarball (<media_num>.linuxabi.tar.gz)
from the root directory / on the target.
5. Log in to the target as root and enter the following command on the
target console:
target# export LD_LIBRARY_PATH=/usr/lib:/lib
NOTE: The value of LD_LIBRARY_PATH can be determined from the output of the
ldd command on the Linux applications intended to be run (as described in an
earlier section of this chapter).
6. Transfer the file $ENV_PREFIX/usr/lib/ld.so.1 from the

LynxOS cross-development system to the target directory /usr/lib
and use the chmod command to make this file executable. Then, create a
symbolic link /lib/ld.so.1 that points to the file
/usr/lib/ld.so.1 (this is crucial for the Linux ABI layer to start
working).
host# rcp $ENV_PREFIX/usr/lib/ld.so.1 \
root@<target_IP>:/usr/lib
target# chmod a+x /usr/lib/ld.so.1
target# cd /lib
target# ln -s ../usr/lib/ld.so.1 ld.so.1
target# ls -l ld.so.1
lrwxrwxrwx 1 root 18 Sep 26 14:57 ld.so.1 ->
../usr/lib/ld.so.1
7. Proceed to run the Linux applications on LynxOS target.

The following is a sample set of open-source/COTS applications verified on Linux
ABI. For a full list of applications, please contact the LynuxWorks Technical
Support team.
• ACE 5.4.8—TAO 1.4.8—a cross-platform framework of object-oriented
classes to help in the development of communication software, and a
standards-compliant real-time C++ implementation of CORBA.
• Apache Axis C++ 1.4—a non-Java implementation of Axis with a C++
runtime engine. It allows you to create C++ client-side stubs and server-
side skeletons that can be deployed to either a full Apache web server or a
Simple Axis server for testing.

• Apache Tomcat 5.5.12—the servlet container used for Java Servlet and
Java Server Pages technologies.
• Apache Axis 1.1 with Tomcat 5.5.12— an implementation of Simple
Object Access Protocol (SOAP), a lightweight XML-based protocol for
exchanging structured information in a decentralized, distributed
environment, and the servlet container used for Java Servlet and Java
Server Pages technologies.
• Apache Portable Runtime 1.2.2—a library of routines that provide a
predictable and consistent interface to underlying platform-specific
implementations. allowing software developers to write a program once
and be able to compile it anywhere.
• gSOAP 2.7.6c—Generator Tools for Coding SOAP/XML Web Services
in C and C++.
• jUDDI 0.9 rc3—an open source Java implementation of the Universal
Description, Discovery, and Integration (UDDI), which provides a
standard interoperable platform to quickly, easily, and dynamically find
and use Web services over the Internet.
• JXTA-C v2.3—a C-bind reference implementation of the JXTA peer-to-
peer network protocol on top of TCP/IP, HTTP, and other network
transports.
• OpenSSL 0.9.7d—an open source implementation of the Secure Sockets
Layer (SSL) and Transport Layer Security (TLS) protocols.
• Oracle9i Release 2—a database that provides high performance and
scalable manageability of data.
• PostgreSQL 8.0.1—an open source Java implementation of the Universal
Description, Discovery, and Integration (UDDI), which provides a
standard interoperable platform to quickly, easily, and dynamically find
and use Web services over the Internet.
• Qt 3.3.5—a C++ application development framework that provides
cross-platform development tools for GUI layout and forms design,
internationalization, and documentation. It provides an extensive C++
class library. With Qt, you can create native applications for all major
operating systems.
• UDDi4j 2.0.2—a Java class library that provides an API to interact with a
UDDI (Universal Description, Discovery and Integration) registry. UDDI
enables businesses to quickly and dynamically find and transact with one
another by way of their preferred applications.

Example—Linux ABI Usage
• unixODBC v2.2.9—a common driver manager for accessing DBMS. It

provides the definitive standard for ODBC on non-MS Windows
platforms.
• Xalan C++ 1.8.0—an XSLT processor for transforming XML documents
into HTML, text, or other XML document types.
• Xerces-C++ 2.5.0—a validating XML parser, written in a portable subset
of C++, that makes it easy for your applications to read and write XML
data. It provides a shared library for parsing, generating, manipulating,
and validating XML documents.
• Xerces-J 2.6.2 and Xalan-J 2.6.0—a family of software packages for
parsing and manipulating XML, and a program that implements XSLT
XML transformation language and XPath XML query language.
• zlib 1.2.3—an open-source, cross-platform data compression library and
an abstraction of the compression algorithm used in gzip.
Example—Linux ABI Usage

This example demonstrates how to create and boot a LynxOS KDI using Linux
ABI to run a Linux application. In the example the /usr/X11R6/bin/xev
program from the Red Hat Enterprise Linux 3 development host will be run on
LynxOS booted onto the x86 target with the Intel PRO/100 Ethernet driver. The
display of the development host will be used for the program graphical output. The
example assumes that the development host IP address is 192.168.1.1 and the
target IP address is 192.168.1.2.
Use the following procedure to create the KDI:
1. Set up the LynxOS cross-development environment with Linux ABI
support on the Red Hat Enterprise Linux 4 or Red Hat Enterprise linux
5.1 development host. Make sure the Linux ABI Compatibility Layer
package is installed.
$ . SETUP.bash x86
2. Change to the BSP directory and customize the KDI specification file:
$ cd sys/bsp.x86_pc
$ vi net.spec

Append the following lines at the end of this file to include the
application and its shared libraries into the KDI:
# LinuxABI
directory=/test owner=0 group=0 mode=drwxr-xr-x

file=xev source=/usr/X11R6/bin/xev owner=0 group=0 mode=-r-xr-xr-x
directory=/lib owner=0 group=0 mode=drwxr-xr-x

file=ld-linux.so.2 source=$(ENV_PREFIX)/lib/ld-linux.so.2 owner=0 \
group=0 mode=-r-xr-xr-x
file=libdl.so.2 source=/lib/libdl.so.2 owner=0 group=0 mode=-r--r--r--
file=libc.so.6 source=$(ENV_PREFIX)/lib/tls/libc.so.6 owner=0 group=0 \
mode=-r--r--r--
directory=/usr/X11R6/lib owner=0 group=0 mode=drwxr-xr-x

file=libXaw.so.7 source=$(ENV_PREFIX)/usr/X11R6/lib/libXaw.so.7 owner=0 \
group=0 mode=-r--r--r--
file=libXmu.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libXmu.so.6
owner=0 group=0 mode=-r--r--r--
file=libXt.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libXt.so.6 owner=0\
file=libSM.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libSM.so.6 owner=0\
file=libICE.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libICE.so.6
file=libXpm.so.4 source=$(ENV_PREFIX)/usr/X11R6/lib/libXpm.so.4 \
file=libXext.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libXext.so.6\
file=libX11.so.6 source=$(ENV_PREFIX)/usr/X11R6/lib/libX11.so.6 \
Note that the xev executable and the libdl.so.2 shared library are
not contained in the Linux ABI distribution and should be copied from
the Red Hat Linux environment.
3. To enable TCP/IP and the Intel PRO/100 Ethernet driver in the kernel,
edit the sys/bsp.x86_pc/config.tbl file. Comment out the
I:nullnux.cfg line and uncomment the I:hbtcpip.cfg and
I:fxp.cfg lines.
4. Build the KDI:

$ make all
$ make netkdi
5. Enable remote X11 clients on the development host:
$ xhost +
6. Boot the KDI on the target and then type in the target shell:
$ ifconfig fxp0 192.168.1.2
$ export DISPLAY=192.168.1.1:0
$ /test/xev

CHAPTER 10 XFree86 and LessTif
This chapter provides the following information on XFree86 and LessTif:

• Components overview and source baseline
• Libraries linkage
• Utilities linkage
• Multithreaded library support
• Supported LynxOS 5.0 Board Support Packages (BSPs)
• Supported LynxOS 5.0 cross-development hosts
• Supported hardware
• X server configuration
• XFree86 demo system
• DRI support

Chapter 10 - XFree86 and LessTif
Components Overview and Source Baseline

The X11 Product Development Package includes the components described in
Table 10-1.
Table 10-1: X11 Product Development Package Components
Component Version Description
ATK 1.9.0 The open source library that provides a set of

interfaces for adding accessibility support to
applications and graphical user interface toolkits
available from the GTK+ organization.
Expat 2.0.0 The open source stream-oriented library for
(x86 only)1) parsing XML texts available from the Expat XML
Parser organization.
FontConfig 2.3.2 The open source library for font customization and
(x86 only)1) configuration available from the FontConfig
organization.
FreeType 2.1.10 The open source software font engine designed to
(x86 only)1) be small, efficient, highly customizable, and
portable while capable of producing high quality
output available from the FreeType Project
organization.
Gettext 0.14.5 The open source set of tools that provides a basic
framework for producing multilingual messages
available from the GNU Project organization.
GLib 2.6.6 The open source low-level core library that forms
the basis of GTK+ available from the GTK+
organization.
GTK+ 2.6.10 The open source multiplatform toolkit for creating
graphical user interfaces available from the GTK+
organization.
JPEG 6b The open source library for JPEG image
compression available from the Independent JPEG
Group organization.
LessTif 0.93.36 An open source version of Motif available from
the Hungry Programmers organization.

Libraries Linkage
Table 10-1: X11 Product Development Package Components (Continued)
Component Version Description
LibArt 2.3.19 The open source LGPL version of the LibArt

library available from the Academic Computer
Club Umea University.
Libiconv 1.10 The open source Unicode-to-traditional encoding
conversion library available from the GNU Project
organization.
Libpng 1.2.8 The open source official PNG reference library
available from the Libpng organization.
Mesa2) 6.2.1 An open source version of the OpenGL graphics
library available from the XFree86 Project, Inc.
Mesa demos 6.2.1 The Mesa demo applications available from the
Mesa Project.
Pango 1.8.2 The open source library for laying out and
rendering texts, with an emphasis on
internationalization that forms the core of text and
font handling for GTK+ 2.x available from the
GTK+ organization.
XFree86 4.3.0 An open source version of X11 available from the
XFree86 Project, Inc.
1. For the PowerPC platform, support for the Expat v1.95.2, FontConfig v1.0.1, and
FreeType v.2.1.1 is integrated into XFree86 package.
2. The Mesa 3D graphics library is integrated into the XFree86 package.
Libraries Linkage
All libraries are present in the static and shared (dynamic) forms.
Utilities Linkage
All utilities are dynamically linked.

Multithreads Support
All libraries are present in the multithreaded form.
Supported LynxOS 5.0 BSPs

The supported LynxOS 5.0 BSP is described in Table 10-2.
Table 10-2: Supported LynxOS 5.0 BSP
Platform BSP
x86 x86_pc
PowerPC radppc7d
PowerPC cwdy4_183
NOTE: Since there is no video output on the supported PowerPC boards, these
boards have only partial XFree86 and Lesstif support. In particular, the DRI mode
is not supported and only the remote XFree86 server is supported. The information
given below in this Chapter uses the x86_pc as a reference.
Supported LynxOS 5.0 Cross-Development Hosts

The supported LynxOS 5.0 cross-development host is described in Table 10-3.
Table 10-3: Supported LynxOS 5.0 Cross-Development Host
BSP Cross-Development Host
x86_pc PC running Red Hat Enterprise Linux 4 or Red

Hat Enterprise Linux 5.1

Supported Hardware
Supported Hardware
Supported Targets
The target supported by LynxOS 5.0 X11 Product is listed in Table 10-4.
Table 10-4: Supported Target
BSP Target
x86_pc x86 PC
Graphics Adapter Support

The graphics adapter supported by the X11 Product is listed in Table 10-5.
Table 10-5: Supported Graphics Adapter
BSP Graphics Adapter
x86_pc Intel 855GM, integrated1)

Intel 945, integrated2) 3)
Intel 965, integrated2) 3)
1. The video adapter is supported via the i810_drv.o driver. Refer to “Using the
i810_drv.o and i810_xorg_7.2.0_drv.o X Server Video Drivers” on page 96.
2. The video adapter is supported via the i810_xorg_7.2.0_drv.o driver. Refer to
“Using the i810_drv.o and i810_xorg_7.2.0_drv.o X Server Video Drivers” on page 96.
3. The video adapter is supported in the non-DRI mode only.
Mouse Support
The mouse supported by the X11 Product is listed in Table 10-6.
Table 10-6: Supported Mouse
BSP Mouse
x86_pc Generic 3-button optical USB mouse

Keyboard Support
The keyboards supported by the X11 Product are listed in Table 10-7.
Table 10-7: Supported Keyboards
BSP Keyboard
x86_pc Generic 104-key USB keyboard

Generic 104-key PS/2 keyboard
Monitor Support
The monitor supported by the X11 Product is listed in Table 10-8.
Table 10-8: Supported Monitor
BSP Monitor
x86_pc Generic CRT monitor1)
1. Single monitor connected to the video adapter D-Sub output.
Using the i810_drv.o and i810_xorg_7.2.0_drv.o X Server

Video Drivers
The XFree86 distribution provides two versions of the i810 video driver located in
the $ENV_PREFIX/usr/X11R6/lib/modules/drivers directory:
• i810_drv.o - the most recent version of the native XFree86 i810
video driver. i810_drv.o provides support for the i855GM graphics
adapter.
• i810_xorg_7.2.0_drv.o - the X.Org Foundation X11R7.2 version
of the i810 video driver. i810_xorg_7.2.0_drv.o provides support
for the i945/i965 graphics adapters.
The i810_drv.o and the i810_xorg_7.2.0_drv.o files cannot be used
simultaneously. On the target board, one of these files should be placed into the

X Server Configuration
/usr/X11R6/lib/modules/drivers directory as i810_drv.o. To include

the i810_drv.o driver, the mkimage spec file shall contain the following lines:
directory=/usr/X11R6/lib/modules/drivers
file=i810_drv.o source=$(ENV_PREFIX)/usr/X11R6/lib/modules/drivers/i810_drv.o
To include the i810_xorg_7.2.0_drv.o driver, the mkimage spec file shall

contain the following lines:
directory=/usr/X11R6/lib/modules/drivers
file=i810_drv.o source=$(ENV_PREFIX)/usr/X11R6/lib/modules/drivers/i810_xorg_7.2.0_drv.o
On the development host, the i810_drv.o manual page is available by the

man i810 command while the i810_xorg_7.2.0_drv.o manual page is
available by the man i810_xorg_7.2.0 command.
X Server Configuration
This section explains how to edit the XF86Config configuration file to configure
the X server.
The XFree86 binary distribution provides the XF86Config X server configuration
file located in the $ENV_PREFIX/usr/X11R6/lib/X11 directory. This
configuration file is suitable for all hardware supported by this X11 Product
release. By default, the provided XF86Config file allows the X server to configure
the video adapter to use the 1024x768 monitor resolution and 24 bit per pixel (bpp)
color depth.
This section describes how to edit the XF86Config file to set custom color depth
and monitor resolution.
Setting Color Depth and Monitor Resolution

To set a custom color depth, set the DefaultDepth variable in the Section
"Screen" of the XF86Config file to the desired value (the supported color depths
are: 8, 16, and 24 bpp). To set a custom monitor resolution, set the Modes variable
of the SubSection "Display" corresponding to the chosen color depths to the
desired value. For instance:
Section "Screen"
. . .
DefaultDepth 16

. . .
SubSection "Display"
Depth 16
Modes "1600x1200"
EndSubSection
. . .
EndSection
XFree86 Demo System
XFree86 Demo System Overview

The LynxOS 5.0 distribution provides the xfree86
($ENV_PREFIX/usr/demo/xfree86) demo system (as a part of the standard
LynxOS demo systems that can be downloaded on the target board) that
demonstrates basic functionality of the XFree86 X server. The following X utilities
are included in the xfree86 demo system:
• The native XFree86 twm or LessTif mwm window manager
• A simple application like xterm, xcalc, xclock, oclock, and xeyes
• A number of the Mesa demos (bounce, osdemo, gears, glutfx, and
others).
Configuring XFree86 Demo System

By default, the xfree86 demo supports the following features:
• i945/i965 video adapters
• The twm window manager
• Dynamically linked X applications
NOTE: The Mesa demos are not supported by default.
To configure the xfree86 demo to support the i855 video adapter, to support the
Mesa demos, to operate in context of the mwm window manager or use the
statically linked X applications, the
$ENV_PREFIX/usr/demo/xfree86/xfree86.spec file should be updated
manually before LynxOS demo systems are installed.

Preparing the Target Boards
Specifically:
• To configure the xfree86 demo to support the i855 video adapter, the
strings that follow the “# Comment for i855” messages shall be
commented out, while the strings that follow the “# Uncomment for
i855” messages on the contrary shall be uncommented
• To configure the xfree86 demo KDI to support the Mesa demos,

uncomment the lines between # Uncomment these lines for Mesa
and # End of Mesa entries.
Also, the following lines should be uncommented in the Module section
of the $ENV_PREFIX/usr/demo/xfree86/x86_pc_XF86Config
file:
# Load "glx"
# Load "speedo"
# Load "type1"
# Load "dri"
• To configure the xfree86 demo to operate in context of the mwm

window manager, the strings that follow the “# Comment for MWM
environment” messages shall be commented out, while the strings that
follow the “# Uncomment for MWM environment” messages on the
contrary shall be uncommented
• To configure the xfree86 demo to use the statically linked X
applications, all strings between the “# Comment these lines for
static XFree86 environment” and “# End of XFree86
dynamic entries” message pairs shall be commented out.
Preparing the Target Boards

Before booting the xfree86 demo KDI, a target board must be prepared. The
following sections provide the detailed instructions on how the supported target
board is prepared.
Preparing the x86 PC Board

To prepare the x86 PC target board, perform the following steps:
1. Connect the video console to the video card.
2. Insert the supported keyboard/mouse devices to the target board. Refer to
“Supported Hardware” on page 95 for the list of supported
keyboard/mouse devices.

Starting an X Session
To start an X session on the target board, the following command must be
executed:
# startx
After an X session is started, the twm or mwm window manager as well as a couple
of the xterm windows and the xclock application are run automatically. To start
another X applications, an appropriate command must be executed from the xterm
command line, or an appropriate entry from the mwm menu (initiated by clicking in
the free space of the root window in context of the mwm window manager) must be
used.
Running the Mesa Demos

To run Mesa demos, enter into the usr/examples/mesa-6.2.1/demos
directory on the target board and run the specified Mesa demos, for example.
# ./bounce
Stopping an X Session
To stop an X session, use the Ctrl-Alt-Backspace key combination.
Running the X Server in the Direct Rendering Mode
NOTE: The i945/i965 video adapters are supported in the indirect rendering mode
only.
The X server can run in the both direct and indirect rendering modes. In the
indirect rendering mode the 2D and 3D acceleration is performed by the X
software. In the direct rendering mode the acceleration is performed by graphics
hardware.
The X server runs in the direct rendering mode in case the following conditions are
fulfilled:
• The video chip DRI driver is configured into the LynxOS kernel

Configuring the Kernel
• The DRI support is enabled in the X server configuration file
Configuring the Kernel

By default, the video chip DRI driver is commented out in the kernel configuration
file. To include the driver into the kernel, perform the following steps:
1. Log in to the system and enable the LynxOS cross-development
environment by sourcing the SETUP.bash script on top of LynxOS tree.
2. Uncomment the following string in the
$ENV_PREFIX/sys/bsp.x86_pc/config.tbl file:
#I:i915.cfg

$ cd $ENV_PREFIX/sys/bsp.x86_pc
$ make all
The new kernel ($ENV_PREFIX/sys/bsp.x86_pc/a.out) includes the video
chip DRI driver.
Enabling Direct Rendering in the X Server Configuration

File
The default $ENV_PREFIX/usr/X11R6/lib/X11/XF86Config file created
upon installation of the X11 Product enables direct rendering. The following
sections of the file are related to direct rendering:
• The “Module” section:
Section “Module”
...
Load "glx"
Load "dri"
End Section
These strings allow the X server to load the modules that handle direct
rendering.
• The “DRI” section:
Section “DRI”
Group 0
Mode 0666
End Section
This section is used to restrict access to direct rendering. By default,

direct rendering is allowed for any user with a current connection to the X

server. To restrict the use of direct rendering to a certain group of users

(for example, for a group with the group ID equal to 2), set the Group and
Mode variables as shown below:
Group 2
Mode 0660
Building XFree86 Demo System with the Direct Rendering

Enabled
To build the XFree86 demo system with the direct rendering enabled, perform the
following steps:
1. Update the $ENV_PREFIX/usr/demo/bsp/x86_pc file adding the
I:i915.cfg specification to the XFREE86_CFG variable.
XFREE86_CFG=”\
I:usb.cfg
I:mousemgr.cfg
I:i915.cfg”
2. Mesa should be enabled for Direct Rendering. Refer to “Configuring

XFree86 Demo System” on page 98.
3. Build the XFree86 demo system using the PROJECT.sh script.
How to Check That the Direct Rendering Mode is Used

To check what mode is used in the current X session the glxinfo utility can be
used. It is a useful program for examining the OpenGL vendor, renderer and
version lines. Among the output the following string can be present:
direct rendering: Yes
That means that the X server uses the direct rendering.
Running the Mesa Demos with the Direct Rendering

Enabled
In order to run the Mesa demos with the direct rendering enabled, the priority of
the X server should be increased by one using the setprio utility before the
Mesa demos are executed.
# setprio +1 <pid>
where <pid> is the PID number of the X server. To determine the PID number of
the X server (the X process), the ps utility could be used.

APPENDIX A Glossary
API - Application Programming Interface - A language interface used by programs

to access the operating system and/or applications.
Board Support Package - See BSP.
Boot - The sequence of events, from system power up to starting an operating
system and/or application on a system - In order to boot, a boot loader must
retrieve a bootable image (OS or application executable) from disk, EPROM, or
over a network.
BSP - Board Support Package - A collection of programs and device drivers that
allow an operating system or other piece of software to execute on a particular
hardware platform.
CDK - See Cross development kit.
Compiler - A program or collection of programs that converts source code into
either assembly language or executable machine code.
Context switch - The process of suspending a currently running thread, task, or
process, and beginning or resuming the execution of another thread - In LynxOS
there are at least three kinds of context switches: User threads within a virtual
address space (process), User threads across virtual address spaces (inter-process),
and LynxOS kernel threads.
Cross development - The process of developing an application or kernel on a host
system configuration (Linux or Windows, for example) that is different from the
target system configuration where the application is to be deployed.
Cross development environment - The cross development environment includes
LynxOS-specific compilers, linkers, libraries, and other development tools. For
example, GDB - the LynuxWorks version of the GNU debugger, is provided with
LynxOS. The LynxOS cross development environment allows for creating
LynxOS applications and kernels from a variety of platforms.

Appendix A - Glossary
Cross development kit - A suite of LynxOS cross development tools specific to a

particular host system configuration - Supported cross development kit platforms
include Windows, Linux, and Sun/Solaris.
Device driver - Software that facilitates the interfacing of applications or programs
with system hardware.
Debugger - A tool for debugging - Specifically, one that facilitates the controlled
execution of a program and the inspection of program data.
Determinism - The attribute of a system displaying known and measurable
performance characteristics - The kinds of determinism of interest to real-time
developers include maximum blocking times, interrupt latencies, and context
switch times.
DRM - Device Resource Manager - LynxOS module that manages buses and
devices on a system - The DRM provides a standard set of services and calls used
to access buses and devices.
Embedded system - A combination of hardware and software designed to perform
a specific function.
Firmware - Software that has been written to ROM.
Flash memory - EPROM that can be erased and rewritten by software.
Hard real-time - A hard real-time system must always meet specific deadlines. In
a soft real-time system, deadlines can be missed. A hard real-time system is used to
denote a critical environment where deadlines cannot be missed. See also Real-
time operating system.
High availability - The utilization of distributed computer resources to maximize
system uptime and provide failsafe mechanisms for hardware or software failures
Host - A computer or operating system that communicates with a target system via
a serial port or network connection - In cross development environments, the host
system is where applications are developed. Also see Target.
Inter-process communication - The act and the mechanisms for communication
and synchronization among threads, tasks, or processes - IPCs include control
variables, mutexes, queues, and semaphores.
Interrupt - A hardware event, such as the arrival of data on an I/O port, that causes
a specific asynchronous software response, that is, the program stops its current
activity to service the interrupt. The LynxOS model of interrupt processing is to
field the interrupt in the device driver, but to perform actual processing in LynxOS
kernel threads.

KDI - Kernel Downloadable Image - KDIs combine a LynxOS kernel and
associated applications into bootable images designed for easy downloading to
target systems.
Kernel - The core of the operating system that handles thread or task creation,
scheduling, and synchronization.
Kernel threads - In LynxOS, kernel threads provide processing service to device
drivers.
Linker - A utility program that combines the object code output of a compiler or
an assembler to create an executable program.
Microcontroller - Similar to microprocessors, microcontrollers are designed
specifically for use in embedded systems.
Microprocessor - A silicon chip that contains a general-purpose CPU
MMU - Memory Management Unit - The circuitry present in a microprocessor or
sometimes in a separate device to allow for the protection of regions of system
memory and for the mapping & translation of logical (program) addresses into
physical memory address to implement virtual addressing.
Native development - The process of developing applications on the same
platform and environment that the application is to be deployed on - Also see
Cross development.
Netboot - Booting an application or kernel image across a network instead of from
ROM or a disk.
ODE - Open Development Environment - The native LynxOS development
environment - An ODE consists of LynxOS native versions of GNU compilers, the
LynxOS/GNU linker, libraries, ROMing tools, utilities, and other utilities. Also see
Cross development kit.
Policy - A set of user-defined behaviors in a system - In real-time, policy usually
refers to the rules for scheduling threads of like priority.
POSIX - Portable Operating System Interface - A family of standards based on
UNIX system V and Berkeley UNIX that defines the interface between
applications and an operating system for maximum compatibility and portability
across implementations.
Preemption - The interruption of thread execution by the operating system for the
purpose of rescheduling - Preemption occurs when a program’s time-slice or
quantum has expired, or when a higher-priority thread becomes ready to run. In
LynxOS, the operating system itself is preemptible.

Appendix A - Glossary
Priority - The relative importance of a thread of execution - Priorities are

represented in numerical values. LynxOS offers 256 unique priorities. In a hard
real-time system, the thread with the highest priority that is ready to run always
runs.
Process - An executing program - In LynxOS, processes are virtually addressed
containers for globally structured threads.
PROM - Programmable Read-Only Memory.
Real-time operating system - An operating system that responds to events and
input immediately - General operating systems, such as DOS or UNIX, are not
real-time.
RAM - Random Access Memory - Volatile memory type that allows data to be
written to and erased to/from it
ROM - Read Only Memory - Non-volatile memory type that only allows
read-access.
RTOS - See Real-time operating system.
Scheduling - The process of determining which thread or task is allowed to run on
a system - Hard real-time scheduling is based on priority. If two threads exist at the
same priority, scheduling is then based on policy.
Target - The system on which an application is deployed - Typically, the target
system is synonymous with embedded system. Also see Host.
Task - The basic schedulable entity in most operating systems, especially real-time
operating systems - Usually synonymous with process.
Thread - Part or parts of a program that can be executed independent of the parent
process.
Virtual addressing - The use of an MMU to provide applications the illusion of a
logical address space - Each virtual address space is isolated from other
applications and their virtual address spaces, except as requested by memory
sharing inter-process communications. Virtual addressing translates the program-
local logical addresses into physical addresses, and maps blocks of physical
memory into logical address spaces only as needed.
Virtual memory - The extension of physical memory (RAM) onto long-term
storage, typically a disk drive, through the use of virtual addressing and swapping.
X Windows - A graphical user interface and windowing environment for UNIX
systems.

Index
boot code 9
bootable images, creating 59
Symbols booting LynxOS
booting KDIs 66
/sys directory 39, 41
BSP 7, 9
/devices directory 44
/lib kernel library files 42
modifiable directories 42
overview 41
symbolic link to BSP directory 43
C
/sys/bsp./uparam.h file 47
CONFIG.TBL, adding/removing drivers 45
/sys/bsp//uparam.h file contacting LynuxWorks xii
configurable parameters for dynamic
CPU Support Package. See CSP.
memory 47
creating KDIs with mkimage 59–??
/sys/bsp<bsp_name>/uparam.h file 48 cross-development environment
/sys/lbsp//uparam.h file
setup scripts 46
configurable parameters for dynamic
CSP 7, 9
memory 48 customizing
/sys/lynx.os directory 43
/sys directory 41
overview 43
kernel 39, 43
customizing the default LynxOS kernel
configuration 39–57
A
a.out file 44, 45
adding
D
device drivers with CONFIG.TBL 45
demos, KDI 71
functionality to a kernel 56
device drivers
adding 56
adding or removing 45
CONFIG.TBL file 43, 45
B modifying 55
dynamic 10
Board Support Package (BSP)
removing unused 55
location 41, 45
static 10
symbolic link to 43
device info files
Board Support Package. See BSP.
dynamic 10

Index
static 10
Device Resource Manager. See DRM.
directories K
kdi 69
KDI
personal kernel build 45
booting 66
disk space
over network 66
determining usage 52
RAM memory map 67
dlopen() 26
build templates 67
documents
getting started 70
Writing Device Drivers for LynxOS 40, 57
building demos 71
DRM 9
components 59
dynamic device drivers 10
creating a sample KDI 67
dynamic device info files 10
creating an image 63
dynamic kernel size, modifying 48, 52
creating spec file 64
dynamic memory, modifying 47
enabling RAM disk driver 64
modifying kernel parameters 64
testing 66
creation procedure overview 63
E file system component 61
embedded root file system, KDIs 61 embedded rfs 61
embedded standalone file system
embedded standalone file system image,
image 61
KDIs 61
environment 3 kernel component 60
mkimage utility 59
environment variables
overview 59
$ENV_PREFIX 45, 46
LD_LIBRARY_PATH 81 text segment component 62
kernel 9
Makefile 56
adding functionality 56
PATH 46
changes made to /sys/devices 44
changing static size 52
customization, main directory 43
customizing for functionality 40
F customizing for maximum processes 49
file system customizing for performance 39, 47
for KDIs 61 customizing for size 40, 52
files components 52
target support 41, 45 symbol table information 52
customizing from a cross-development
host 46
determining disk space usage 52
G determining memory usage 53
determining size 52
Glossary 103 library files, location 42
loading 56
modifying dynamic size 48, 52
personal build directory 45
H reasons to customize 39
rebuilding with make utility 44
host, customizing kernel from 46 kernel build directories, creating individual 45
Kernel Downloadable Images (KDIs) 59

LynxOS kernel files, location 39, 41
L
ld.so.1 76, 77, 81
Linux ABI compatibility 75–90
M
Linux ABI compatibility Layer
make utility 44
Linux Reference Distribution 82 Makefile
Linux ABI compatibility layer 76
environment variables 56
adding Linux libraries to LynxOS 79
rules 44
dynamically linked applications 82 target-specific 43
extracting RPMs 86
memory usage, kernel 53
installing and running Opera 89
mkimage utility 59
ld.so.1 dynamic linker 76 disk-based file system 61
libraries included 77
kernel image components 60
limitations 85
RAM-based file system 61
versioned symbols 82 specification file 60, 64
Linux ABI libraries
specifying embedded file system 61
adding to LynxOS 79
specifying kernel image 60
specifying paths 81
specifying resident text segments 62
updating 80 syntax and features 60
Linux binary applications 75
testing images made 66
determining Linux libraries needed 79
-mshared option 26, 37
running on LynxOS 76 multiple kernel build directories 46
shared object interface calls 76
location
BSP 41, 45
kernel library files 42
LynxOS kernel files 39, 41
O
setup scripts 46 online information x
LynuxWorks, contacting xii Opera 89
LynxOS Overview
architecture 7 shared libraries 25
background 3 overview 1
customizing default kernel 39, 43 of /sys 41
environment 3 of /sys/lynx.os 43
features 4
kernel image components 60
kernel images 59, 63
loading kernel images over a network 66 P
mkimage utility 59
shared libraries provided 36 PIC 25
shared libraries supported 25 preboot utility 66
specifying the embedded file system 61 processes, increasing on LynxOS 49
specifying the kernel image 60 PROJECT.sh, for demo KDIs 70
specifying the resident text segments 62
steps for building kernel images 63
testing kernel images 66
understanding 3
LynxOS applications, native 75, 77

Index
testing kernel images 66
R
RAM disk driver, enabling 64
RAM memory map, netbooting KDIs 67
U
resident text segments, for KDIs 62
understanding LynxOS 3
resident text, use of 62
RPMs, extracting with rpm2cpio 86
W
S Writing Device Drivers for LynxOS 40, 57
setup scripts, location 46
SETUP.bash 46
SETUP.csh 46
Shared Libraries 25–??
X
and single/multithreaded applications 26 XIP text segments 62
Choosing Contents 35
Code Maintenance 28
Creating 37
Determining use of 29
Disk Space Usage 28, 35
effects 27
factors in memory usage 27
kinds supported 25
linking to 37
object files included 25
overview 25
program maintenance 36
provided in LynxOS 36
System Memory Usage 27
Updating 35
shared Libraries
Linux ABI Libraries 77
size, kernel 52
SKDB 40
static device drivers 10
static device info files 10
static kernel size, changing 52
system services 8
T
targets
files, location 41, 45
target-specific Makefile 43
Technical Support xii

0806 02 Los5 - Ug

Uploaded by

Copyright:

Available Formats

0806 02 Los5 - Ug

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0806 02 Los5 - Ug

Uploaded by

Copyright:

Available Formats

3

LynxOS User’s Guide

Copyright ©1987 - 2010, LynuxWorks, Inc. All rights reserved.

Printed in the United States of America.

CHAPTER 1 OVERVIEW ................................................................................................ 1

CHAPTER 2 UNDERSTANDING LYNXOS........................................................................ 3

CHAPTER 3 LYNXOS ARCHITECTURE ........................................................................... 7

LynxOS User’s Guide iii

Dynamic Device Info Files .................................................................... 10

CHAPTER 4 SYMMETRIC MULTIPROCESSING (SMP) ................................................... 11

CHAPTER 5 SUPPORT FOR POSIX.13 PSE53 SYSTEM PROFILE IN LYNXOS................ 15

CHAPTER 6 SHARED LIBRARIES .................................................................................. 25

iv LynxOS User’s Guide

CHAPTER 7 CUSTOMIZING THE DEFAULT

CHAPTER 8 CREATING KERNEL DOWNLOADABLE IMAGES ........................................... 59

LynxOS User’s Guide v

Resident Text Segments ................................................................................ 62

CHAPTER 9 LINUX ABI COMPATIBILITY ...................................................................... 75

vi LynxOS User’s Guide

APPENDIX A GLOSSARY ............................................................................................ 103

INDEX ............................................................................................................ 107

LynxOS User’s Guide vii

viii LynxOS User’s Guide

For More Information

LynxOS User’s Guide ix

• LynxOS Networking Guide

Kind of Text Examples

Environment variables, filenames, ls

x LynxOS User’s Guide

Kind of Text Examples

Commands that need to be highlighted login: myname

Text that represents a variable, such as a cat <filename>

Blocks of text that appear on the display Loading file /tftpboot/shell.kdi

LynxOS (ppc) created Mon Jul 17

Keyboard options, button names, and Enter, Ctrl-C

NOTE: These callouts note important or useful points in the text.

LynxOS User’s Guide xi

How to Submit a Support Request

xii LynxOS User’s Guide

Where to Submit a Support Request

Support, Europe tech_europe@lnxw.com

Training and courses USA: +1 408-979-4353

Support, Europe +33 1 30 85 06 06

LynxOS User’s Guide xiii

xiv LynxOS User’s Guide

LynxOS User’s Guide 1

2 LynxOS User’s Guide

LynxOS User’s Guide 3

What LynxOS Offers

4 LynxOS User’s Guide

• Partial POSIX 1003.13-2003 PSE54 support—

• Red Hat Enterprise Linux 3-compliant Linux ABI (GLIBC 2.3.3)

LynxOS User’s Guide 5

o Internet Group Management Protocol, Version 3 specification per

6 LynxOS User’s Guide

LynxOS Operating System

LynxOS User’s Guide 7

Figure 3-1: LynxOS Architecture

• POSIX API LynxOS provides services as specified in the POSIX 1003.13-2003