VxWorks Kernel Shell®USER'S GUIDE
6.9
Edition 3
Copyright © 2011 Wind River Systems, Inc.
All rights reserved. No part of this publication may be reproduced or transmitted in any
form or by any means without the prior written permission of Wind River Systems, Inc.
Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc.
The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party
trademarks referenced are the property of their respective owners. For further information
regarding Wind River trademarks, please see:
http://www.77cn.com.cn/company/terms/trademark.html
This product may include software licensed to Wind River by third parties. Relevant
notices (if any) are provided in your product installation at the following location:
installDir/product_name/3rd_party_licensor_notice.pdf.
Wind River may refer to third-party documentation by listing publications or providing
links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.
Corporate Headquarters
Wind River
500 Wind River Way
Alameda, CA 94501-1153
U.S.A.
Toll free (U.S.A.):800-545-WIND
Telephone: 510-748-4100Facsimile: 510-749-2010
For additional contact information, see the Wind River Web site:
http://www.77cn.com.cn
For information on how to contact Customer Support, see:
http://www.77cn.com.cn/support
VxWorks Kernel Shell
User's Guide
6.9
Edition 326 Oct 11
Contents
1Overview ......................................................................................................
1.1Introduction ......................................................................................................................
1.2Related Documentation Resources ..............................................................................
1.3VxWorks Configuration and Build ..............................................................................2Kernel Shell .................................................................................................
2.1Introduction ......................................................................................................................
2.2About the Kernel Shell ..................................................................................................
2.3About the C Interpreter and Command Interpreter .................................................
2.4About Wind River CLI Shell Access ...........................................................................
2.5About Kernel and HostShell Differences .................................................................
2.6Configuring VxWorks With the Kernel Shell ...........................................................
2.6.1Required Kernel Shell Components ...............................................................
2.6.2Optional Kernel Shell Components ................................................................
2.7Setting Configuration Variables for Kernel Shell Sessions ...................................
2.7.1Kernel Shell Configuration Variables ............................................................
2.7.2Configuring Kernel Shell Configuration Variables Statically .....................
2.7.3Configuring Kernel Shell Configuration Parameters Dynamically ...........
2.8Starting the Kernel Shell ...............................................................................................
2.9Using Kernel Shell Help ................................................................................................
2.10Using Kernel Shell Control Characters .......................................................................
2.11Calling C Routines From the C Interpreter ................................................................
Calling VxWorks Image Routines by Name .................................................11223445668810121213131414151616
iii
VxWorks Kernel ShellUser's Guide, 6.9 Calling Downloadable Kernel Module Routines by Name ........................
Argument Limit .................................................................................................
2.12Aborting Routines Executing from the Kernel Shell ...............................................
2.13Switching Between Interpreters ..................................................................................
2.14Switching Between Kernel and RTP Memory Contexts .........................................
2.15Executing Commands With the Inactive Interpreter ................................................
2.16Kernel Shell History .......................................................................................................
2.17Defining Kernel Shell Command Aliases ..................................................................
2.18Debugging With the Kernel Shell ..............................................................................
2.18.1Using Dynamic Printf ......................................................................................
Configuring VxWorks for Dynamic Printf ....................................................
Dynamic Printf Example ..................................................................................
2.18.2Debugging Kernel Tasks .................................................................................
2.18.3Debugging RTP Applications .........................................................................
Adding Dynamic Printfs to RTP Applications .............................................
Starting Tasks and Calling Routines in a Real-Time Process .....................
Monitoring System Calls .................................................................................
2.18.4Debugging SMP Systems With the Kernel Shell .........................................
2.19Kernel Shell Security .....................................................................................................
2.20Using a Remote Login to the Kernel Shell .................................................................
2.21Launching a Shell Script Programmatically ..............................................................
2.22Executing Shell Commands Programmatically .........................................................
2.23Accessing Kernel Shell Data Programmatically .......................................................
2.24Adding Custom Commands to the Command Interpreter .....................................
2.24.1Creating A New Command .............................................................................
Defining a Command .......................................................................................
Writing the Command Routine ......................................................................
Registering a New Command .........................................................................
2.24.2Sample Custom Commands ............................................................................
2.25Creating a Custom Interpreter ......................................................................................
2.25.1Sample Custom Interpreter .............................................................................
3Kernel Object-Module Loader ....................................................................
3.1Introduction ......................................................................................................................iv161617181819191919202020212222222425262627273030313132333434363939
3.2About the Kernel Object-Module Loader ..................................................................
3.2.1Relocatable ELF Object Files ............................................................................
3.2.2Processing the Contents of an ELF Object File ..............................................
3.2.3Linking and Reference Resolution ..................................................................
3.3Kernel and Host Loader Differences ...........................................................................
3.3.1Relationship to VxWorks Target .....................................................................
3.3.2Module and Symbols Synchronization ..........................................................
3.3.3Memory management ......................................................................................
3.3.4System Debug Mode .........................................................................................
3.4Configuring VxWorks with the Kernel Object-Module Loader ............................
3.4.1Compiler Intrinsics Support for C Modules .................................................
3.5Kernel Object-Module Loader APIs and Shell Commands ...................................
3.6Summary List of Kernel Object-Module Loader Options ......................................
3.7Loading C Modules Into the Kernel ............................................................................
3.8Loading C++ Modules into the Kernel .......................................................................
3.8.1Use a Single C++ Module ................................................................................
3.8.2Munching a C++ Application Module ...........................................................
3.8.3Calling Static Constructors and Destructors Interactively ..........................
3.9Memory Location Options for Module Loading .......................................................
3.9.1Default Memory Location for 32-Bit VxWorks .............................................
3.9.2Default Memory Location Options for 64-bit VxWorks ..............................
Using the 64-Bit Kernel Proximity Heap .......................................................
Using the 64-Bit Kernel Common Heap ........................................................
3.9.3Specific Memory Locations for 32-Bit and 64-Bit VxWorks ........................
3.10Caveats for Kernel Object-Module Loader Use ........................................................
3.10.1Module Types Must Match VxWorks System ..............................................
3.10.2Load Sequence Requirements .........................................................................
3.10.3Resolving Common Symbols ..........................................................................
3.10.4Resolving Weak Symbols .................................................................................
3.10.5Stripping Symbols From Modules ..................................................................
3.10.6Function Calls, Relative Branches, and Load Failures .................................
3.10.7Kernel Object Modules With SDA ..................................................................
3.10.8Unresolved Symbols and Compiler Intrinsics .............................................. Contents394041414242434343444545465050515153535354545555565657575859595960
v
VxWorks Kernel ShellUser's Guide, 6.9 4Kernel Symbol Table ..................................................................................
4.1
4.2Introduction ......................................................................................................................About Kernel Symbol Tables .......................................................................................616161
4.2.1System Symbol Table ........................................................................................
4.2.2Symbol Entries ...................................................................................................
4.2.3Symbol Updates ................................................................................................
4.2.4Searching the Symbol Library .........................................................................
4.3Configuring VxWorks with Symbol Tables ..............................................................
4.3.1Configuration for User Symbol Tables ..........................................................
4.3.2Configuration for a System Symbol Table .....................................................
4.4Creating a Built-In System Symbol Table ..................................................................
4.4.1Generating the Symbol Information ...............................................................
4.4.2Compiling and Linking the Symbol File ........................................................
4.5Creating a Loadable System Symbol Table ...............................................................
4.5.1Creating the .sym File .......................................................................................
4.5.2Loading the .sym File .......................................................................................
4.6Synchronizing Host and Kernel Modules List and Symbol Table .......................
4.7Creating and Using User-Defined Symbol Tables ...................................................
5Show Routines ............................................................................................
5.1Introduction ......................................................................................................................
5.2About VxWorks Show Routines ..................................................................................
6Common Problems .....................................................................................
6.1Introduction ......................................................................................................................
6.2Kernel Shell Debugging Never Hits a Breakpoint ...................................................
6.3Insufficient Memory .......................................................................................................
6.4Download "Relocation Does Not Fit" Error Message ..............................................
6.5Missing Symbols .............................................................................................................
6.6Kernel Object-Module Loader is Using Too Much Memory .................................
6.7Symbol Table Unavailable ............................................................................................
6.8Kernel Shell Debugging is Slow ..................................................................................vi626363636464646565656666666667696969717171727373747475
1
Overview
1.1Introduction1
1.2Related Documentation Resources2
1.3VxWorks Configuration and Build2
1.1 Introduction
The Wind River host development environment provides tools that reside and
execute on the host machine. This approach conserves target memory and
resources. However, there are many situations in which it is desirable to make use
of target-resident facilities: a target-resident shell, kernel object-module loader,
debugging facilities, and system symbol table. The uses for these target-resident
tools include the following:
■Debugging a deployed system over a serial connection.
Developing and debugging network protocols, where it is useful to see the
target's view of a network.
Loading kernel modules from a target disk, from ROMFS, or over the network,
and running them interactively (or programmatically). ■■
The target based tools are partially independent of each other. For example, the
kernel shell may be used without the kernel object-module loader, and vice versa.
However, for any of the other inpidual tools to be completely functional, the
system symbol table is required.
In some situations, it may be useful to use both the host-resident development
tools and the target-resident tools at the same time. In this case, additional facilities
are required so that both environments maintain consistent views of the system.
(For more information, see 4.6Synchronizing Host and Kernel Modules List and
Symbol Table, p.66.)
This guide describes the features and use of the VxWorks target-resident kernel
shell, object-module loader, debugging facilities, and system symbol table. It also
provides an overview of the most commonly used VxWorks show routines, which are executed from the shell.
1
VxWorks Kernel ShellUser's Guide, 6.9
1.2 Related Documentation Resources
Detailed information about VxWorks libraries and routines is provided in the
VxWorks API references. Information specific to target architectures is provided in
the VxWorks BSP references and in the VxWorks Architecture Supplement. For
information about the host shell, see the WindRiver Workbench Host Shell User’s
Guide.
1.3 VxWorks Configuration and Build
This document describes VxWorks features and their use; it does not go into detail
about the mechanisms by which VxWorks systems are configured and built. The
tools and procedures used for configuration and build are described in the Wind
River Workbench by Example guide and the Wind River Platforms User’s Guide.
NOTE: In this guide, as well as in the VxWorks API references, VxWorks
components and their configuration parameters are identified by the names used
in component description files. The names take the form, for example, of
INCLUDE_FOO and NUM_FOO_FILES (for components and parameters,
respectively).
You can use these names directly to configure VxWorks using the command-line
configuration facilities.
Wind River Workbench displays descriptions of components and parameters, as
well as their names, in the Components tab of the Kernel Configuration Editor.
You can use the Find dialog to locate a component or parameter using its name or
description. To access the Find dialog from the Components tab, type CTRL+F, or
right-click and select Find.
2
2
Kernel Shell
2.1Introduction4
2.2About the Kernel Shell4
2.3About the C Interpreter and Command Interpreter5
2.4About Wind River CLI Shell Access6
2.5About Kernel and HostShell Differences6
2.6Configuring VxWorks With the Kernel Shell8
2.7Setting Configuration Variables for Kernel Shell Sessions12
2.8Starting the Kernel Shell14
2.9Using Kernel Shell Help14
2.10Using Kernel Shell Control Characters15
2.11Calling C Routines From the C Interpreter16
2.12Aborting Routines Executing from the Kernel Shell17
2.13Switching Between Interpreters18
2.14Switching Between Kernel and RTP Memory Contexts18
2.15Executing Commands With the Inactive Interpreter19
2.16Kernel Shell History19
2.17Defining Kernel Shell Command Aliases19
2.18Debugging With the Kernel Shell19
2.19Kernel Shell Security26
2.20Using a Remote Login to the Kernel Shell26
2.21Launching a Shell Script Programmatically27
2.22Executing Shell Commands Programmatically27
2.23Accessing Kernel Shell Data Programmatically30
2.24Adding Custom Commands to the Command Interpreter30
2.25Creating a Custom Interpreter34
3
VxWorks Kernel ShellUser's Guide, 6.9
2.1 Introduction
The VxWorks kernel shell is a target-resident shell that can be accessed locally
from a host system over a serial connection using a terminal utility (such as tip or
HyperTerminal), remotely over a network connection (using telnet, rlogin), or
using the wtxConsole.1
2.2 About the Kernel Shell
The VxWorks kernel shell provides a shell interface that can be used to execute,
monitor, and debug kernel and RTP code, as well as to monitor and debug general
system performance. For most uses, the kernel shell requires the system symbol
table. It can also be used with the kernel object module loader to download object
code into kernel space (for information in this regard, see 3.Kernel Object-Module
Loader).
The kernel shell has two interpreters—the C interpreter and the command
interpreter—each of which has its own set of commands. The C interpreter can also
be used to execute any VxWorks kernel routines, or any routines that have been
added to kernel space with downloadable kernel modules. The command
interpreter, on the other hand, is similar to a UNIX shell. In contrast with the C
interpreter (for which all commands are C system functions), the command
interpreter commands are statically registered. This means that the command
interpreter can be used without the system symbol table.
For the most part, the target-resident kernel shell works the same as the host shell,
except that it executes entirely in the target system. In addition, the kernel shell
only provides the C interpreter and command interpreter (others may be
registered by the user), whereas the host shell provides additional facilities (see
2.5About Kernel and HostShell Differences, p.6 for information about other
differences).
For detailed information about the host shell and the shell interpreters, see the
WindRiver Workbench Host Shell User’s Guide, and the online Wind River Host Shell
API Reference.
Multiple kernel shell sessions may be run simultaneously, which allows for
simultaneous access to the target from the host console and remote connections
made with telnet or rlogin.
NOTE: VxWorks is a single-user operating system. It does not support
simultaneous use by more than one user. While multiple kernel shell sessions may
be run concurrently, they must all be started by the same user. The kernel shell can,
however, be configured so that each shell session has its own current working
directory variable.
1.In versions of VxWorks prior to 6.0, the kernel shell was called the target shell. The new
name reflects the fact that the target-resident shell runs in the kernel and not in a process.
4
2 Kernel Shell
2.3 About the C Interpreter and Command Interpreter
NOTE: The kernel shell operates only with int, long, short, char, double, or float
data types.
CAUTION: Do not use hardware breakpoints with the kernel shell and an On-Chip
Debugging (OCD) tool at the same time. Simultaneous use may lead to
unpredictable debugging behavior, as both facilities access hardware breakpoint
registers.
2.3 About the C Interpreter and Command Interpreter
The kernel shell includes both a C interpreter and a command interpreter. Their
basic differences are as follows:
■The command interpreter is designed primarily for starting, monitoring, and
debugging real-time process (RTP) applications. It can also be used in
conjunction with the kernel object module loader to load and unload kernel
object modules. It provides a UNIX-like shell environment.
The C interpreter is designed primarily for monitoring and debugging
kernel-based code. It can be used for loading, running, and unloading object
modules in conjunction with the kernel object-module loader. In addition, it
provides some APIs for starting and monitoring RTP applications. The C
interpreter operates on C routines, whether provided by VxWorks libraries or
user’s kernel code that is either linked with VxWorks or downloaded into the
target system.
CAUTION: When a routine is called from the kernel shell, the routine is ■executed in the context of the shell task. If execution of the routine hangs, the
shell session will hang as well.
For detailed information about the interpreters, see the WindRiver Workbench Host
Shell User’s Guide. For information about the commands supported by each
interpreter, see Interpreter Commands and References, p.5.
For information about adding new commands to the command interpreter, and
creating interpreters for the kernel shell, see 2.24Adding Custom Commands to the
Command Interpreter, p.30 and 2.25Creating a Custom Interpreter, p.34.
For information about help available from the kernel shell itself, see 2.9Using
Kernel Shell Help, p.14.
Interpreter Commands and References
For information about inpidual C interpreter routines, see the usrLib, dbgLib,
and usrShellHistLib sections in the VxWorks Kernel API Reference, as well as
entries for the various show routine libraries. The dbgLib routines are particularly
useful, providing commands for managing task breakpoints, task single-stepping,
symbolic disassembly, and symbolic task stack tracing.
Note that the kernel shell can also call any C routine that returns a data type
supported by the shell (int, long, short, char, double, or float). For example,
5
VxWorks Kernel ShellUser's Guide, 6.9 semaphores can be created and manipulated from the shell using the VxWorks
semaphore APIs.
2.4 About Wind River CLI Shell Access
The Wind River CLI shell can be accessed from the kernel shell, provided that
VxWorks has been appropriately configured with Wind River CLI support. For
information in this regard, see the Wind River CLI, Web, MIBway Programmer's
Guide.
2.5 About Kernel and HostShell Differences
The major differences between the target and host shells are the following:
■The host and kernel shells do not provide exactly the same set of commands.
The kernel shell, for example, has commands related to network, shared data,
environment variables, and some other facilities that are not provided by the
host shell. However, the host and kernel shells provide a very similar set of
commands for their command and C interpreters.
Each shell has its own distinct configuration parameters, as well as those that
are common to both.
Both shells include a command and a C interpreter. The host shell also
provides a Tcl interpreter and a gdb interpreter. The gdb interpreter has about
40 commands and is intended for debugging processes (RTPs); and it
references host file system paths.
For the host shell to work, VxWorks must be configured with the WDB target
agent component (see the VxWorks Kernel Programmer’s Guide: WDB Target
Agent). For the kernel shell to work, VxWorks be configured with the kernel
shell component, as well as the target-resident symbol tables component.
The host shell can perform many control and information functions entirely on
the host, without consuming target resources.
The kernel shell does not require any Wind River host tool support.
The host shell uses host system resources for most functions, so that it remains
segregated from the target. This means that the host shell can operate on the
target from the outside, whereas the kernel shell is part of the VxWorks kernel.
For example, the host shell version of the w() command does not allocate
memory on the target, whereas the kernel shell version of w() does allocate
memory on the target. Conflicts in task priority may also occur while using the kernel shell.■■■■■■
6
2 Kernel Shell
2.5 About Kernel and HostShell Differences
!WARNING: Shell commands must be used in conformance with the routine
prototype, or they may cause the system to hang.
■The kernel shell has its own set of terminal-control characters, unlike the host
shell, which inherits its setting from the host window from which it was
invoked. (See 2.10Using Kernel Shell Control Characters, p.15.)
The kernel shell correctly interprets the tilde operator in path names for UNIX
and Linux host systems (or remote file systems on a UNIX or Linux host
accessed with ftp, rsh, NFS, and so on), whereas the host shell cannot. For
example, the following command executed from the kernel shell (with the C
interpreter) by user panloki would correctly locate the kernel module
/home/panloki/foo.o on the host system and load it into the kernel:
->ld<~/foo.o ■
■When the kernel shell encounters a string literal (“...”) in an expression, it
allocates space for the string, including the null-byte string terminator, plus
some additional overhead.1 The value of the literal is the address of the string
in the newly allocated storage. For example, the following expression allocates
12-plus bytes from the target memory pool, enters the string in that memory
(including the null terminator), and assigns the address of the string to x:
->x="hellothere"
The following expression can be used to return the memory to the target
memory pool (see the memLib reference entry for information on memory
management):
->free(x)
Furthermore, even when a string literal is not assigned to a symbol, memory
is still permanently allocated for it. For example, the following expression uses
memory that is never freed:
-> printf("hellothere")
This is because if strings were only temporarily allocated, and a string literal
was passed to a routine being spawned as a task, by the time the task executed
and attempted to access the string, the kernel shell would have already
released (and possibly even reused) the temporary storage where the string
was held.
If the accumulation of memory used for strings has an adverse effect on
performance after extended development sessions with the kernel shell, you
can use the strFree() routine (with the C interpreter) or the equivalent
stringfree command (with the command interpreter).
The host shell also allocates memory on the target if the string is to be used
there. However, it does not allocate memory on the target for commands that
can be performed at the host level (such as lkup(), ld(), and so on).
1.The amount of memory allocated is rounded up to the minimum allocation unit for the
architecture in question, plus the amount for the header for that block of memory.
7
VxWorks Kernel ShellUser's Guide, 6.9
2.6 Configuring VxWorks With the Kernel Shell
The functionality of the kernel shell is provided by a suite of components, some of
which are required, and others of which are optional.
2.6.1 Required Kernel Shell Components
Table 2-1
8To use the kernel shell, you must configure VxWorks with the INCLUDE_SHELL component. The configuration parameters for this component are described in Table2-1. You must also configure VxWorks with components for symbol table support—unless you are only going to use the command interpreter—using either the INCLUDE_STANDALONE_SYM_TBL or INCLUDE_NET_SYM_TBL component. For information about configuring VxWorks with symbol tables, see 4.3Configuring VxWorks with Symbol Tables, p.64.INCLUDE_SHELL Configuration Parameters Configuration ParameterDescriptionSHELL_SECUREAccess the kernel shell attached to the console through a login process. See 2.19Kernel Shell Security, p.26. SHELL_STACK_SIZEDefault stack size for each instance of a kernel shell task. SHELL_TASK_NAME_BASEThe basename for each instance of a kernel shell task. The default is tShell. An integer is added to the basename to identify each instance of a kernel shell task, starting with zero and incremented for each additional instance. Note that remote shell sessions (such as those initiated by rlogin or telnet) have a task basename of tShellRem. SHELL_TASK_PRIORITYPriority for each instance of a kernel shell task.SHELL_SPAWNED_TASK_STACK_SIZEThe stack size of a task spawned from the shell with sp(), period(), or repeat(). It can subsequently be modified at runtime using the spTaskStackSize global variable; see the usrLib API reference. SHELL_SPAWNED_TASK_PRIORITY The priority of a task spawned from the shell with sp(), period(), or repeat(). It can subsequently be modified at runtime using the spTaskPriority global variable; see the usrLib API reference.
2 Kernel Shell
2.6 Configuring VxWorks With the Kernel Shell
Table 2-1INCLUDE_SHELL Configuration Parameters (cont’d)
Configuration ParameterDescription
SHELL_SPAWNED_TASK_OPTIONS The task options of a task spawned
from the shell with sp(), period(), or
repeat(). It can subsequently be
modified at runtime using the
spTaskOptions global variable; see the
usrLib API reference.
Task creation options for the kernel
shell tasks. For more information about
task creation options, see the VxWorks
Kernel Programmer’s Guide: Multitasking.
The kernel shell is launched
automatically at boot time on the
console.
The kernel shell is configured to be
compatible with the VxWorks 5.5 shell,
with a limit of one shell session, global
I/O redirection, and shell task options
without the VX_PRIVATE_ENV bit. This
option cannot be used with
SHELL_SECURE set to TRUE, with
SHELL_START_AT_BOOT set to FALSE,
or with SHELL_MAX_SESSIONS set to
anything other than -1.
The default configuration variables for
kernel shell sessions. They can
subsequently be modified at runtime.
See 2.7Setting Configuration Variables for
Kernel Shell Sessions, p.12.
The default configuration variables for
the initial kernel shell session can be set
independently of other sessions using
this parameter. They can subsequently
be modified at runtime. See 2.7Setting
Configuration Variables for Kernel Shell
Sessions, p.12. SHELL_TASK_OPTIONSSHELL_START_AT_BOOTSHELL_COMPATIBLESHELL_DEFAULT_CONFIGSHELL_FIRST_CONFIG
9
VxWorks Kernel ShellUser's Guide, 6.9
Table 2-1INCLUDE_SHELL Configuration Parameters (cont’d)
Configuration ParameterDescription
SHELL_REMOTE_CONFIGThe configuration variables for kernel
shell sessions started for a remote
connection can be set independently of
local sessions using this parameter.
They can subsequently be modified at
runtime. See 2.7Setting Configuration
Variables for Kernel Shell Sessions, p.12.
The maximum number of shell
sessions. The default is unlimited
(defined with -1). When a session limit
is set and reached, further connections
are rejected (with a message to the
console). The limitation is enforced
whether or not the sessions are secured
(that is, authenticated) and whether or
not they are local (console shell or
remote shell). The limitation is
independent of any that might be
implemented by a telnet, rlogin, or SSH
server. SHELL_MAX_SESSIONS
2.6.2 Optional Kernel Shell Components
Table2-2 describes components that provide additional shell functionality.
Table 2-2Optional Shell Components
ComponentDescription
INCLUDE_DEBUGDebugging facilities, such as disassembly,
task stack trace, setting a breakpoint,
stepping, and so on.
Display the shell banner on startup.
Editing mode similar to the vi editing mode.
Editing mode similar to the Emacs editing
mode.
C interpreter. See 2.3About the C Interpreter
and Command Interpreter, p.5.
Command interpreter. See 2.3About the C
Interpreter and Command Interpreter, p.5.
Kernel shell startup script facility.
Shell history commands. INCLUDE_SHELL_BANNERINCLUDE_SHELL_VI_MODEINCLUDE_SHELL_EMACS_MODEINCLUDE_SHELL_INTERP_CINCLUDE_SHELL_INTERP_CMDINCLUDE_STARTUP_SCRIPTINCLUDE_SHELL_HISTORY_FILE
10
2 Kernel Shell
2.6 Configuring VxWorks With the Kernel Shell
Table2-3 describes components that provide additional command interpreter
functionality. They must be used with the INCLUDE_SHELL_INTERP_CMD
component (described above in Table2-2).
Table 2-3Command Interpreter Components
ComponentDescription
INCLUDE_DISK_UTIL_SHELL_CMD
INCLUDE_EDR_SHELL_CMD
INCLUDE_TASK_SHELL_CMD
INCLUDE_DEBUG_SHELL_CMD
INCLUDE_SYM_SHELL_CMD
INCLUDE_VM_SHOW_SHELL_CMD
INCLUDE_ADR_SPACE_SHELL_CMDFile system shell commands.Error detection and reporting shell commands.Task shell commands.Debug shell commands.Symbol shell commands.Virtual memory show shell commands.Address space shell
commands.
commands.INCLUDE_SHARED_DATA_SHOW_SHELL_CMDShared data show shell
INCLUDE_MEM_EDR_SHELL_CMD
INCLUDE_MEM_EDR_RTP_SHELL_CMDMemory detection and reporting shell commandsMemory detection and
reporting shell commands for
processes (RTPs).
Kernel loader shell command.
Kernel unloader shell
command.
Shared library commands for
processes.
Process shell commands.
Process show shell
commands.
Shell history commands. INCLUDE_MODULE_SHELL_CMDINCLUDE_UNLOADER_SHELL_CMDINCLUDE_SHL_SHELL_CMDINCLUDE_RTP_SHELL_CMDINCLUDE_RTP_SHOW_SHELL_CMDINCLUDE_HISTORY_FILE_SHELL_CMD
Additional components that are useful are the following:
INCLUDE_DISK_UTIL
Provides file utilities, such as ls and cd (it is required by
INCLUDE_DISK_UTIL_SHELL_CMD).
INCLUDE_SYM_TBL_SHOW
Provides symbol table show routines, such as lkup.
It can also be useful to include components for the kernel object-module loader
and unloader (see 3.4Configuring VxWorks with the Kernel Object-Module Loader,
11
VxWorks Kernel ShellUser's Guide, 6.9 p.44). These components are required for the usrLib commands that load modules
into, and unload modules from, the kernel (see 3.7Loading C Modules Into the
Kernel, p.50 and 3.8Loading C++ Modules into the Kernel, p.50).
Note that the BUNDLE_STANDALONE_SHELL and BUNDLE_NET_SHELL
component bundles are also available to provide for a standalone kernel shell or a
networked kernel shell.
2.7 Setting Configuration Variables for Kernel Shell Sessions
Kernel shell configuration variables are used to control various settings for shell
sessions, including identifying the current shell interpreter (command or C), line
edit mode (vi or Emacs), and so on. It can be useful to think of these variables as
session variables. Note that the shell’s configuration variables are not VxWorks
environment variables (which are themselves unlike UNIX environment variables;
for more information about environment variables, see the envLib entry in the
VxWorks API references).
The defaults for configuration variables are set initially as part of configuring
VxWorks and the kernel shell at build time (statically). They can subsequently be
modified at runtime (dynamically).
2.7.1 Kernel Shell Configuration Variables
The kernel shell provides several configuration variables itself, and other facilities
provide additional variables. Some of the shell’s configuration variables are the
following:
INTERPRETER
Identify the interpreter, either C or Cmd. The default is the first interpreter
registered (the C interpreter).
LINE_EDIT_MODE
Set the line edit mode, either Emacs or vi. The default is the first line edit mode
style registered (vi mode).
LINE_LENGTH
Set the shell line length (it cannot be changed dynamically). The default is 256
characters.
The set of configuration variables that are available depends on the configuration
of the VxWorks system itself. For example, RTP_CREATE_STOP is only available if
VxWorks is configured with process support and the command interpreter
component (INCLUDE_RTP and INCLUDE_SHELL_INTERP_CMD).
The kernel shell’s variables are listed in the shellLib API reference. Others are
listed in the API references associated with their functionality (for example,
taskspawn, which provides RTP_TASK_SPAWN_PRIO,
RTP_TASK_SPAWN_STACK_SIZE and RTP_TASK_SPAWN_OPTS).
12
2 Kernel Shell
2.7 Setting Configuration Variables for Kernel Shell Sessions2.7.2 Configuring Kernel Shell Configuration Variables Statically
The default values for kernel shell configuration variables are set statically—when
VxWorks is configured using Workbench or the vxprj tool—with the following
component parameters:
SHELL_DEFAULT_CONFIG
The default settings of configuration variables for all shell sessions, except for
any configuration variables overridden (on a variable by variable basis) by
SHELL_FIRST_CONFIG or SHELL_REMOTE_CONFIG for the first or remote
sessions, respectively.
SHELL_FIRST_CONFIG
Configuration variables for the initial shell session launched at boot time.
Overrides SHELL_DEFAULT_CONFIG for any configuration variables set. By
default it is set to NULL.
SHELL_REMOTE_CONFIG
Configuration variables for remote sessions (telnet or rlogin). Overrides
SHELL_DEFAULT_CONFIG for any configuration variables set. By default it is
set to NULL.
Each of these parameters can be set to a string of configuration variables or used to
change inpidual values.
For example, to set the path to RTP application executables with the VXE_PATH
configuration parameter from the command-line you would use the following
command:
vxprj parameter setstring SHELL_DEFAULT_CONFIG "VXE_PATH=/home/xeno:/romfs"
This example illustrates setting multiple configuration parameters at once:
vxprj parameter setstring SHELL_DEFAULT_CONFIG
"LINE_EDIT_MODE=emacs,LINE_LENGTH=256,STRING_FREE=manual,INTERPRETER=Cmd,VXE_PAT
H=.;/romfs"
Note that commas are used to separate arguments.
2.7.3 Configuring Kernel Shell Configuration Parameters Dynamically
Kernel shell configuration variables can be changed dynamically at runtime (either
interactively or programmatically) for a shell given session.
Configuration variables can be changed using shConfig() with the C interpreter,
or using the setconfig command with the command interpreter. They can also be
changed programmatically using shellConfigDefaultSet() to set defaults for all
sessions, and shellConfigSet() to set variables for a particular session.
For example, the following shell command changes line-edit mode to Emacs:
[vxWorks]# set config LINE_EDIT_MODE="emacs"
13
vxworks_kernel_shell_users_guide_6.9相关文章：
