TOC PREV NEXT INDEX

LynxOS User's Guide

w

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:

By default, the LynxOS kernel on the bootable installation media contains all supported disk and terminal drivers for a given hardware architecture. This allows a single bootable disk/CD-ROM to load LynxOS for initial installation on a wide range of hardware configurations.

To enable LynxOS kernel customization for optimal performance, functionality, and/or size on any given system, during its initial installation, users must make some basic configuration choices. These include the device from which distribution media are to be read, the disk/partition onto which data is loaded, adding networking support, and so on.

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:

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:

For example, LynuxWorks creates a bootable LynxOS kernel image that fits onto a high-density floppy for installation onto certain x86 systems. LynuxWorks customizes the boot kernel so that the kernel image, certain installation utilities (LynuxWorks installit application), and the RAM disk file system all fit within 1.44 MB.

Customizing for Functionality

The third common scenario involves customizing the functionality of the LynxOS kernel. This includes adding or removing the following components:

Users may also need to add their own, custom device drivers for a particular application.

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

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:

/sys Directory Contents
File/Directory
Description
Makefile
The top-level Makefile
OBJ_RULES
Contains the Makefile rules
bsp.xxx
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.
drivers/bsptype
Contains the BSP-specific device driver source files.
include
Contains the kernel header files
lib
Contains the kernel and driver library archives. (See Table 72 "sys/lib Kernel Library Files").
lynx.os
This is a symbolic link to the bsp.xxx directory.
romkit
Contains examples for building bootable kernel images.

sys/lib Kernel Library Files  
Library Name
Description
libmisc.a
Miscellaneous support routines
libnfs_server.a
NFS server code
libsyscalls.a
System call interface
libdevices.a
Common devices
libdevices.bsptype.a
BSP-specific devices
libkernel.a
Kernel routines
libnullnfs.a
Null NFS driver
libtcpip.a
TCP/IP code (IPv4 and extras)
libtcpip6.a
TCP/IP code (IPv6 and IPSec)
libdrivers.a
Common device drivers
libdrivers.bsptype.a
BSP-specific device drivers
libnfs_client.a
NFS Client code

Note: Debug versions of all kernel library files also exist in the /sys/lib directory, indicated there by a *_d.a extension.

For information on the contents, functionality, and building a debug version of a kernel library file, see "Creating a Kernel for Debugging".

Of all the directories in the /sys directory, users are most likely to modify files in the /bsp.xxx directory, as accessed through the /sys/lynx.os symbolic link. Users can, however, also modify files in the following /sys directories:

However, these files should only be modified 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 /sys/lynx.os. It is a symbolic link to the directory bsp.xxx, where xxx represents the Board Support Package (BSP) that supports the targeted hardware (that is, the configuration on which the custom application is to be deployed).

The symbolic link from lynx.os to bsp.xxx provides the flexibility to add support for target hardware variants, while maintaining a consistent build environment and access to supporting scripts via the /sys/lynx.os path.

Overview of /sys/lynx.os

The /sys/lynx.os directory contains the following files and subdirectories:

/sys/lynx.os Directory Contents  
File/Directory
Description
CONFIG.TBL
The control file used for adding/removing device drivers
CONFIG.h
An automatically generated header file
Makefile
The target-specific Makefile
Makefile.common
The makefile that is used by all LynxOS targets; included in Makefile.
*.o
Files with this extension are the prebuilt object files.
info.c
The device information table
conf.c
The configuration 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.c
Contains LynxOS version information.
scripts
Shell functions that are used during a make install.xxx, make uninstall.xxx, or make all.xxx

Rebuilding a Kernel with the make Utility

To rebuild a kernel, change directory to the /sys/lynx.os directory, and run the make utility with a specified Makefile rule (see Table 74 "/sys/lynx.os Makefile Rules"), using the following syntax:

# cd /sys/lynx.os
# make rule

The following Makefile rules are defined in /sys/lynx.os/Makefile:

/sys/lynx.os Makefile Rules
Rule
Description
all
Rebuilds a.out (LynxOS kernel) in the current directory.
a.out
Same as make all
clean
Removes a.out, CONFIG.h, sysdevices.h, nodetab, and timestamp.o.
install
Rebuilds a.out, copies /lynx.os to /lynx.os.old, copies a.out to /lynx.os, and copies nodetab to /etc/nodetab.
install.xxx
Adds the xxx functionality (tcpip, nfs, skdb, or all) to a.out, then installs it. For more information, see the install man page.
uninstall.xxx
Removes the xxx functionality (tcpip, tcpip6, nfs, skdb, or all) from a.out then installs it.
all.xxx
Adds the xxx functionality (tcpip, tcpip6, nfs, skdb, or all) to a.out
SYS_DEBUG=true
Can build a debug kernel with hardware watchpoint support and code test.

Note: The implication of the install rule in the kernel Makefile is as follows: The process of "installing" a kernel involves copying the kernel to the root directory as /lynx.os and copying the device nodetab file to /etc/nodetab. The "installed" kernel, /lynx.os, is usually the default bootable kernel at system startup. Old kernel files are copied to *.old.

Incorporating Changes Made in /sys/devices into the Kernel

To incorporate changes made in /sys/devices into the kernel, perform the following steps:

  1. Change to the /sys/devices directory.

# cd /sys/devices
  1. Add or update the appropriate device file to the /sys/devices directory.

  2. Rebuild the kernel. For example:

# make install

Functionality Scripts

Users can also use the scripts in /usr/bin to install or remove the following major functional modules:

For example, to add support for NFS, enter the following command:

# /usr/bin/Install.nfs

To remove SKDB support from the kernel, enter the following command:

# /usr/bin/Uninstall.skdb

To add support for TCPIP (IPv4 and extras), enter the following command:

# /usr/bin/Install.tcpip

Please note that if Install.tcpip6 is entered in place of Install.tcpip, you will add support for IPv6 and IPSec to the kernel.

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 /sys/lynx.os/CONFIG.TBL on a LynxOS x86 system:

# Secondary 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:

# Secondary ide controller
#I:ide.cfg

Similarly to enable support for TCPIP6, the following lines from CONFIG.TBL must be uncommented, as follows:

I:hbtcpip.cfg
n:hbtcpipv6:@hbtcpip0::

To reflect this change, the kernel must be rebuilt.

Caution! When building a new kernel after changing CONFIG.TBL, the device nodes for the new kernel may not match the previous nodes. The device nodes should be built after making the new kernel; for more information, see the mknod man page.

Whenever CONFIG.TBL is changed to build a new kernel, the device nodes for the new kernel must also be rebuilt. Since the major and minor device numbers may change when editing CONFIG.TBL, users may also have to modify the root device settings to boot LynxOS.

Here are some guidelines for managing changes to CONFIG.TBL:

Making a Personal Kernel Build Directory

When working on team projects, developers may need to maintain individual kernel build environments. The /sys/lynx.os directory was designed with this scenario in mind.

The lynx.os directory (bsp.xxx) is position-independent. That is, it 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 lynx.os 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. $ENV_PREFIX defaults to the root directory (/) on native development systems. On cross development systems, the shell script SETUP.shell defines $ENV_PREFIX when executed: (See "Setting the Cross Development Environment" for more information).

# cp -r /sys/lynx.os /tmp/my_lynx.os
# cd /tmp/my_lynx.os
# touch CONFIG.TBL
# make a.out

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.

Caution! When building native LynxOS kernels, do not invoke the make install command. This option causes the resulting local kernel to overwrite /lynx.os and for the new node table to overwrite /etc/nodetab.

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/lynx/xx/platform, where 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 xxx, loaded onto an x86 development host):

$ cd <install_dir>/usr/lynx/xxx/x86
$ source SETUP.csh
$ cd <install_dir>/usr/lynx/xxx/x86
$ . SETUP.bash

Where <install_dir> is the LynxOS installation directory.

With the exception of having to first invoke a SETUP script on cross development systems, there is no discernible difference in the development process of LynxOS kernels from cross or native machines. LynxOS uses the same Makefiles and directory structure on cross development systems as on native systems.

The design of the /sys directory and Makefile system provides this functionality. The following example demonstrates the similarities in developing kernels on cross development and native LynxOS systems.

Adding TCP/IP to a LynxOS Kernel

In the following commands, TCP/IP IPv4 is added to an x86 cross development system:

$ cd /usr/lynx/x86
$ . SETUP.bash

The following commands then set up the PATH variable that points to the cross development tools, and sets $ENV_PREFIX to point to the installed LynxOS directory tree:

$ cd $ENV_PREFIX/sys/lynx.os
$ make install.tcpip

In this example, the LynxOS kernel (a.out) and the devices nodetab are copied to ENV_PREFIX.

Additionally, the /usr/bin/Install.tcpip script can be used to install TCP/IP onto a system.

In the following commands, TCP/IP is added to a native development system:

$ cd /sys/lynx.os
$ make install.tcpip

In this example, the LynxOS kernel (a.out) and the devices nodetab are copied to $ENV_PREFIX on a native LynxOS system.

Additionally, the /usr/bin/Install.tcpip script can be used to install IPv4 onto a system.

install.tcpip6 will install IPv6, IPSec onto a system. Consult your LynuxWorks sales representative if you would like IPv6/IPSec features.

Note: This procedure applies to IPv4 only.

Customizing a Kernel for Performance

The parameters defined in /sys/lynx.os/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/lynx.os/uparam.h

The table entitled "Default Values for /sys/lynx.os/uparam.h" lists some of the more important configurable parameters in the binary code written for a standard development LynxOS system installation in the /sys/lynx.os/uparam.h file. Other configurable parameters are also contained in this file, and can be found by searching for the character string #define.

The /sys/lynx.os/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 making any changes to /sys/lynx.os/uparam.h, users need to read the comments in the files for any parameter that has been changed. Some parameters depend on others. For example, the value of /sys/lynx.os/uparam.h/NFILES 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/lynx.os/uparam.h

The configurable parameters and their default values in the /sys/lynx.os/uparam.h file are listed in the table below:

Default Values for /sys/lynx.os/uparam.h  
Parameter Name
What the Parameter Defines
Default Value
CACHEBLKS
Disk cache blocks
1024
MAX_FAST_SEMS
Fast semaphores
512
MAXSYMLINKS
Symbolic links in a path
8
NBDEVS
Dynamically-loaded block devices
10
NCDEVS
Dynamically-loaded character devices
20
NDRIVS
Dynamically-loaded drivers
15
NFILES
Open files in system
256
NMOUNTS
Mounted file systems
10
NINODES
In-cache inodes
256
NPIPES
Pipes
50
NPROC
Processes
50
NRLOCKS
File locks
140
NSHLIB
Shared libraries
10
NSOCKETS
Sockets
100
NSTASKS
Kernel threads
20
NTHREADS
User threads
50
NUMIOINTS
Registrable interrupt vectors via iointset(); combined number of interrupt vectors derived by combining number of hardware vectors with software multiplexes
256
NVSEMS
Number of SystemV headers
20
NVSHMS
Number of SystemV-shared memory segments
20
QUANTUM
Clock ticks until preemption
25
SMEMS
LynxOS IPC named shared memory segments
10
USEMS
LynxOS IPC user semaphores
20
USR_NFDS
Open files per process
40
USYNCH
LynxOS IPC pages user synchronization objects
50

Additional Configurable Parameters for Detecting Fatal Errors on an MCP750 Board

Users can enable fatal error detection for LynxOS systems installed in processors mounted on an MCP750 board by adding the following line to the uparam.h file, where xxx is the special device file for a flash memory driver:

#define CRASH_DEVNAME xxx

Note: Not setting CRASH_DEVNAME on MCP750 board systems automatically sets this feature to disabled.

Increasing Maximum Processes

This example illustrates how to customize a LynxOS kernel to handle a greater number of processes. It assumes that the default bootable kernel, /lynx.os, is being modified in order to:

Perform the following steps:

  1. Make a backup copy of uparam.h (to revert to the kernel's original settings) using the following command:

$ cd /sys/lynx.os
$ cp uparam.h uparam.h.old
  1. Use a text editor, such as vi, to edit uparam.h.

  2. Find the parameter NPROC, and increase its number, as follows:

#define NPROC xxx /* max number of\ processes */

Note: The NPROC parameter is being increased to increase the maximum number of processes. Here, xxx represents the NPROC number.

  1. To activate the changes, rebuild the kernel and reboot the system using the following commands:

$ make install
$ reboot -a

Creating a Kernel for Debugging

Users can create debug versions of the LynxOS kernel for use with SKDB and GDB. The debug version of the LynxOS kernel includes support for:

For more information on these functions, see the Total/db User's Guide.

To create a debug version of the LynxOS kernel, use the following when invoking make:

# make all SYS_DEBUG=true

Note: The debug version of the LynxOS kernel should not be used for deployment. Rebuilding the kernel without the debug information results in improved performance.

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:

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 /lynx.os
-rwxr-xr-x 1 root 877060 Oct 29 12:01 /lynx.os

The kernel in this example uses 877060 bytes, or about 877 KB of space.

The size command allows users to look more closely at the sizes of the text, data, and bss segments of the kernel, as illustrated by the command and output below:

$ size /lynx.os
text    data   bss    dec     hex    filename
688096  45056  142300  875452  d5bbc  /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 875452 bytes (or 0xd5bbc).

In addition to the text and data segments, the kernel contains header and symbol table information that take up the additional 1608 bytes, as shown in the command output above.

Determining Kernel Memory Usage

Figuring out the memory usage of the kernel 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 -axonT

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
tid
ppid
pgrp
pri
text
stk
data
time
dev
user
S
name
0
0
0
0
0
0
0
0
25:49
root
R
nullpr
1
7
1
1
16
20
8
12
2.44
root
W
/init
20
12
1
20
18
12
8
8
0.08
atc0
root
W
/bin/syncer
23
48
26
23
17
56
8
36
0.10
root
R
/net/rlogind
26
17
1
26
17
52
8
40
0.01
root
W
/net/inetd
28
18
1
28
17
40
8
52
0.00
root
W
/net/unfsio
31
19
1
31
17
44
12
32
0.03
root
W
/net/portmap
33
20
1
33
17
56
8
52
0.00
root
W
/net/mountd
35
21
1
35
17
44
8
40
0.00
root
W
/net/nfsd
37
22
1
37
17
64
8
44
0.00
root
W
/net/rpc.statd
39
23
1
39
17
60
8
60
0.00
root
W
/net/rpc.lockd.svc
41
24
1
41
17
60
8
68
0.02
root
W
/net/rpc.lockd.clnt
43
11
1
43
17
72
8
40
0.00
root
W
/bin/lpd
45
14
1
45
17
204
28
128
0.26
atc0
root
W
/bin/bash
46
27
1
46
17
204*
28
128
0.27
atc1
root
W
/bin/bash
47
30
1
47
17
204*
28
136
0.74
atc2
root
W
/bin/bash
48
33
1
48
17
204*
28
124
0.19
atc3
root
W
/bin/bash
63
45
46
63
17
340
8
72
0.02
atc1
root
S
/bin/vi
78
41
23
78
17
204*
28
124
0.08
ttyp0
root
W
/bin/bash
119
54
45
119
17
40
8
36
0.08
atc0
root
W
/bin/rlogin
121
55
78
121
17
40
12
40
0.07
ttyp0
root
C
/bin/ps
137
46
48
137
17
340*
12
72
0.04
atc3
root
S
/bin/vi
147
40
119
119
17
40*
8
36
0.06
atc0
root
W
/bin/rlogin
8352K/0K free physical/virtual, 2872K used (in this display)

To calculate the size of the kernel:

  1. Add the amount of free physical memory (8352 KB) to the amount used (2872 KB): 8352 + 2872 = 11224 KB.

  2. Subtract this number from the total amount of memory (RAM) on the LynxOS system.

The machine in this example has 16 MB of memory, which translates to 16384 KB: 16384 - 11224 = 5160 KB.

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 has only one Adaptec 2940 SCSI adapter to control its disk and CDROM drives. It does not need device entries (space used by the kernel) for other LynxOS supported SCSI device drivers.

Before Beginning

  1. Back up the /sys/lynx.os files and directories to /tmp/test by entering the following commands:

$ cp -r /sys/lynx.os /tmp/test
  1. Change to the /tmp/test directory.

$ cd /tmp/test
  1. Record the following information about the kernel:

  2. The /lynx.os file's current size (to be used later in validating that changes have taken effect)

  3. The root file system's device name

  4. The root file system device's major and minor numbers

- Use the ls l or size command to determine the /lynx.os files's current size:
$ ls -l /lynx.os
-rwxr-xr-x 1 root 698924 Oct 29 12:01 /lynx.os
- Use the df command to determine the root file system's device name. In this example, the root file system device name is /dev/sd2940.0a.
$ df /
/dev/sd2940.0a 2048 127992 36979 91013 28%
- Use the ls l command to determine the root file system device's major and minor numbers. In this example, the major number is 4 and the minor number is 16.
$ ls -l /dev/sd2940.0a
brw------- 1 root 4,16 Oct 29 02:33 /dev/sd2940.0a

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:

# Supported LynxOS Adaptec Scsi drivers
#       for SCSI Manager-based Adaptec 154x driver
#I:sim1542.cfg
# NCR 810 SIM (SCSI Interface Module) driver.
#This SCSI driver uses SCSI Manager.
#I: simncr.cfg
#       for SCSI Manager-based Adaptec 294x driver
I:sim2940.cfg

#I:scsi810.cfg
#       for high-level-low-level based ncr 810 driver

Building the Newly Customized Kernel

Use the following procedure to build a new kernel:

  1. Change the working directory to /tmp/test.

$ /tmp/test
  1. Build and install a new LynxOS kernel by entering the following command:

$ make install
After building the new kernel, the installation script generates the file /tmp/test/a.out and copies it to /lynx.os. Additionally, the install script first creates, then copies a new nodetab file from /tmp/test/nodetab to /etc/nodetab, and then generates the file /etc/nodetab.old.

Note: The older versions of generated files are automatically renamed with an .old extension.

  1. Verify that the new kernel has been created by entering the following command:

$ ls -l /lynx.os*
-rwxr-xr-x 1 root 661669 Oct 29 12:01 /lynx.os
-rwxr-xr-x 1 root 698924 Oct 29 12:01 /lynx.os.old
In this example, the size of the new kernel is smaller than the previous kernel by about 36 KB, verifying that the new kernel has accepted the configuration changes made earlier.

Making New Device Nodes

Use the following procedure to create new device nodes.

  1. Make a copy of the old devices directory:

$ mv /dev /dev.old
$ mkdir /dev
  1. Build new device nodes that correspond with the new /etc/nodetab file by entering the following commands:

$ cd /dev
$ mknod -a /etc/nodetab

Loading the New Kernel

Users must know the major and minor number of the new kernel's root file system before rebooting the machine (notice that the major number has changed to 2 in the output below).

  1. Enter the following command to get the new kernel number:

$ ls -l /dev/sd2940.0a
brw------- 1 root 2,16 Oct 29 02:33 /dev/sd2940.0a

Caution! If either a wrong major or minor number is specified as the root device, the error message Main file system failed to install (no dev) may be displayed, or the kernel may crash.

  1. Reboot the system by entering the following command:

$ reboot -a
  1. At the preboot command prompt (the bootstrap kernel loader program), specify the new major and minor number of the root device:

$ Command? R 2 16
$ Setting root device to 2 16
$ Command? b
See the preboot man page for a description of the commands available on the given hardware platform.

Updating the Default Root Device

Now that the new kernel is up and running, users can update the default root device with the makeboot command:

$ makeboot preboot

This command allows users to directly boot LynxOS without using the R command in preboot.

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 /sys/lynx.os/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:

$ mkdir /sys/drivers/my_driver
  1. Use an existing device driver Makefile as a template by entering the following commands:

$ cp /sys/drivers/mem/Makefile
$ /sys/drivers/my_driver
  1. 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=my_driver
These lines instruct the Makefile to compile file*.c files, and to insert the compiled .o files in /sys/lib/my_driver.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.
  1. Modify the Makefile in /sys/lynx.os so that the archive for the device driver is linked to the kernel.

$ CUSTOMER_DRIVERS=$(LIB)/my_driver.a
  1. 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.

  2. Edit the /sys/lynx.os/CONFIG.TBL so that the new driver is represented:

$ I:my_driver.cfg # for instance

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:

  1. Build the LynxOS kernel with the new device driver by entering the following commands:

$ cd /sys/lynx.os
$ make install

Configurable Tick Timer

Users can configure the number of ticks per second for real-time clocks. The define TICKSPERSEC in the /usr/include/conf.h file defaults to 100 ticks per second.

LynuxWorks recommends the following minimum and maximum ticks per second:

Recommended Ticks Per Second value of TICKSPERSEC
Minimum ticks per second
Maximum ticks per second
20 (50ms between ticks)
500 (2ms between ticks)

Configuring Core Files

LynxOS provides the ability to configure the information saved in core files. This allows users to control the size of the core file. This feature can be useful in systems with limited memory or disk resources by storing only the data essential for debugging the application at hand.

Configurable Options

The following options can be set when installing the configurable core file support:

Additionally, users can define the name and location of the core file.

core.seconds.pid

Installing Configurable Core File Capability

Install the configurable core file capability by running either of the following commands:

# /usr/bin/Install.core

or

# cd /sys/lynx.os
# make install.core

Either option starts the same configuration script, allowing the user to update the user defines in uparam.h.

The following figure details a sample configuration dialog session:

Sample Configuration Dialog
bash# cd /sys/lynx.os
bash# make install.core
/bin/make PARSE=Done COMPONENTS="core" install.all
Configuring the Core File Feature ...
Dump the data section [y,n] (y): Enter
Dump the bss section [y,n] (y): Enter
Dump the heap section [y,n] (y): Enter
Dump the shared memory section [y,n] (y): n
Enable Non-POSIX core file naming convention [y,n] (n): y
Please enter the location where the core should be placed [.]: /tmp/altcore

Note: The following combination of the core configuration settings is considered illegal:
  • Data section dump is on

  • BSS section dump is off

  • Heap section dump is on.

With these configuration settings, the data, BSS, and heap sections dumps cannot be saved to the core file in one section as defined by the format of the core. If these configurations are defined, the BSS section will be dumped into the core file.


Restoring the Defaults Settings

To restore the default core file settings, the user must run one of the following commands:

# /usr/bin/Uninstall.core

or

# cd /sys/lynx.os
# make uninstall.core

User Definitions in uparam.h

The configurable core file includes a number of user defines in the LynxOS uparam.h header file. The following table includes the user definitions and default values:

User Defines in uparam.h  
User Defines
Default Value
CORE_WRITE_DATA
1
CORE_WRITE_BSS
1
CORE_WRITE_HEAP
1
CORE_WRITE_SHARED
1
CORE_NONPOSIX_FILENAME
0
CORE_ALTERNATE_LOCATION
NULL

Default Configuration of the Core File

The default settings of the configurable core file in uparam.h are as follows:

These default settings create a conventional core file, effectively disabling any configuration options defined by the configurable core file. Core files created when the default settings are defined in uparam.h are backward compatible with non-configurable core files.



LynuxWorks, Inc.
855 Branham Lane East
San Jose, CA 95138
http://www.lynuxworks.com
1.800.255.5969
TOC PREV NEXT INDEX