![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
The Tornado Launcher is a central control panel that ties together the whole suite of Tornado tools and services. The launcher's mission is to bring together tools and targets; but, as the centerpiece of Tornado, the launcher also provides other services.
The Tornado registry (a daemon that keeps track of all target servers) must be in place on a host at your site before anyone can use Tornado. If the launcher finds no registry, it offers to start one on the current host.1 For more information on the registry and on other host-configuration issues, see 2. Setup and Startup.
To start the Tornado Launcher, invoke its name from the UNIX command line or from any shell script or window-manager menu:2
% launch &
Notice the & in the preceding example. Because the launcher runs in its own separate graphical window, it normally runs asynchronously from its parent shell.
|
|||||||||||||||||||
Most of the main launcher window (Figure 3-1) reflects the two main kinds of objects it links together--tools and target servers:
The target list shows all target servers currently available in your development network. The list scrolls vertically if its contents exceed the display area.
The toolbar has a button for every installed Tornado tool. The toolbar display area scrolls horizontally if its contents exceed the space available. The toolbar illustrated in Figure 3-1 displays the fundamental collection of Tornado tools:
Figure 3-2 illustrates this concept. The launcher allows you to use targets just as easily regardless of their nature or their physical connection. Figure 3-2 shows several common variations on connections between a tool and a target:
All this is possible thanks to the target server, a dedicated daemon which represents each development target to the development network. All details related to physical connectivity are handled by the target server. Someone must configure the target communications initially (see 2.4 Setting Up the Default Target Hardware), but thereafter the target is immediately available to any authorized user on the local network, with no further cabling or configuration.
For reference information about the target server, see the entry for tgtsvr in the online Tornado API Reference (Help>Manuals Contents>Tornado Reference>Tornado Tools>tgtsvr).
To select a target server, click on any of the server names in the target list. The launcher highlights the selected target name, and fills the Information panel with a scrollable description of the target configuration and target server. Figure 3-3 illustrates a launcher with a target server selected.
If no target servers are listed, or if none of the target servers listed represent the target you need, see 3.5.1 Configuring a Target Server below.
If you make a mistake, or if you wish to select another target, simply click on another target-server name. Any tools that you have already launched remain connected to the previous target (the plugboard analogy does not extend that far).
The information panel displays the following information about the selected target:
Once you have selected a target server, click once on any button in the toolbar to launch a tool on that target. You can launch as many instances of a tool as you like, even attached to the same target. For instance, you may find it convenient to have one instance per application task of CrossWind, or to run different shells for different kinds of interaction.
You can also launch many of the Tornado tools from a UNIX shell (or shell script), specifying the target name as an argument. See the chapter that describes each tool for more information.
The target-server architecture of Tornado permits great flexibility, but also introduces a number of housekeeping details to manage situations like the following:
The Target menu in the Tornado Launcher offers commands that allow you to manage these chores and related details to do with target servers. The small buttons immediately below the menu bar provide quick access to the same commands.
The following list describes each button and Target menu command:
|
Define and start up a new target server. See 3.5.1 Configuring a Target Server. |
|||||||||||||||||||
|
Remove the selected target server from the Tornado registry's list of available servers. Do not use this command routinely. Under most circumstances, the registry automatically removes the entry for any target server that has been killed (for example, due to a host system crash). This command can also be used to do so. The registry honors the Unregister command only if the server does not respond to the registry. CAUTION: Even if a target server is not responsive, it is not always appropriate to unregister it; the server may simply be too busy to respond, or a heavy network load may be interfering. The Unregister command reminds you of this possibility and requests confirmation before it takes effect. Make sure the server is really gone before you unregister it. |
|||||||||||||||||||
|
Reconnect the selected target server to the underlying target. This command is rarely necessary, because target servers attempt to reconnect automatically when required. Use this command after turning on or connecting a target that has been unavailable, if you want to reattach a running server explicitly (rather than by running a tool). |
|||||||||||||||||||
|
Restrict a target to your own use, or share it with others. See 3.5.2 Sharing and Reserving Target Servers. |
|||||||||||||||||||
|
Share a target with others. See 3.5.2 Sharing and Reserving Target Servers. |
|||||||||||||||||||
|
Kill the currently selected target server. CAUTION: Close any tool sessions that use a particular target before you kill that target server. Killing a target server does not immediately destroy any attached tools, but the tools lose the ability to interact with the target. There is no way to reconnect a new target server to such orphaned tool sessions. |
|||||||||||||||||||
|
Re-initialize the selected target server and reboot its target. |
|||||||||||||||||||
To use a new target, you must first ensure the host and target are connected properly. The details are unique to each target, but 2.4.2 Networking the Host and Target discusses some of the issues that are frequently involved. Your BSP also contains a target-information reference that describes what to do for that particular target. See Help>Manuals contents>BSP Reference.
To configure and launch a target server, select Create from the Target menu, or press the launcher's
button. The launcher displays the form shown in Figure 3-4. Many configuration options are available, but you can often skip all the optional parameters, specifying only the target name (and perhaps the serial device, if your target agent is configured for the WDB serial protocol).
Each time you specify a configuration option, the Target server launch command box near the bottom of the form is updated automatically to show the tgtsvr command options that capture your chosen configuration. (For text fields, the command line is updated when you select another field or press RETURN.) The tgtsvr command is the underlying command that runs in the background for each target server as a UNIX daemon. The text in the Target server launch command box can be edited. Its display has the following uses:
To start a target server and save your server configuration, press the Launch button at the bottom of the Create Target Server form.
If a server does not respond when you select it, kill it (
) and try turning on the Verbose toggle near the middle of the Create Target Server form to display diagnostic messages when you start it again.
For targets with network connectivity, only one field is required. Fill in the IP address or network name for the target, in the box headed Target name or IP address. After filling this in, you can launch a server immediately. The launcher saves each configuration automatically (identified with the target-server name); thus, you can retrieve a server's configuration later to add more options.
If your target agent is configured for the WDB serial protocol, you must specify what UNIX device name is connected to the target, in the Serial line device box (entering the device name automatically selects wdbserial as the back end in the Backend list field). You must also fill in a name for the target server in the Target name or IP address box; in this case, the name is completely arbitrary, and is used only to identify your target server.
Specifying the serial line speed is not required if you use the default speed of 9600 bps. However, it is best to use the fastest possible line speed when controlling your target over serial lines. Select the fastest speed your target hardware supports from the scrolling list headed Serial line speed. (The target agent must be compiled with the same speed selected; see Configuration for Serial Connection.)
Each time you press the Launch button, the launcher saves the server configuration. The configuration name is the same name used to register the target server: the contents of the Target name or IP address box, or the name specified under Target server name, if you use this box to define a different name for your server.6
The following controls are available to manage saved configurations:
The command buttons at the bottom of the Create Target Server form perform the following functions (see Figure 3-4):
This section describes all the configuration options you can specify in the Create Target Server form(Figure 3-4), in the order they appear (left to right and top to bottom).
This is the default. Click the box to change this option to read only. The default allows you to run WindView. Because read/write also allows other users to access your host file system, you may with to set the TSFS option for your target server to read only when you are not using WindView.
The TSFS provides the most convenient way to boot a target over a serial connection (see 2.6.7 Booting a Target Without a Network).
/usr/windview/logfiles
When a target server is available to anyone, its status (shown in the Information panel of the main launcher window; see Figure 3-3) is unreserved. Any user can attach a tool to the target, and any user can also restrict its use.
When you configure a target server, you can arrange for the server to be exclusively available to your user ID every time you launch it, by clicking the Lock toggle in the Create Target Server form. See 3.5.1 Configuring a Target Server. Target servers launched this way have the status locked.
If a target server is not locked by its creator, and if no one else has reserved it, you can reserve the target server for your own use: click on Target>Reserve, or on the
launcher button. The target status becomes reserved until you release the target with the Unreserve command (
). Unreserve on a target that is not reserved has no effect, nor does Unreserve on a target reserved or locked by someone else.
This simple reserve/unreserve locking mechanism is sufficient for many development environments. In some organizations, however, it may be necessary to further restrict some targets to a particular group of users. For example, a Q/A organization may need to ensure certain targets are used only for testing, while still using the reserve/unreserve mechanism to manage contention within the group of testers.
To restrict a target server to a list of users, create a list of authorized users in a file. The format for the file is the simplest possible: one user name per line. The user names are host sign-on names, as used by system files like /etc/passwd (or its network-wide equivalent). You can also use one special entry in the authorization file: a plus sign + to explicitly authorize any user to connect to the target server. (This might be useful to preserve the link between a target server and an authorization file when access to that target need only be restricted from time to time.)
To link an authorization file to a target server, specify the file's full pathname in the Authorized users file box of the Create Target Server screen (see Figure 3-4).
The About menu has a single command, Tornado, which displays version information for Tornado. This menu appears in all Tornado graphical tools.
The launcher's Support and Info menus are a gateway to Wind River's support, training, and sales services. See 1.6 Customer Services for more information on these launcher facilities.
The Admin menu provides a number of conveniences to automate Tornado administrative chores to the extent possible. The commands in this menu cover installing updates or optional products and managing your site's global authorization file for Tornado.
|
|
NOTE:
If you are not familiar with Tcl, you may want to postpone reading this section (and other sections in this book beginning with "Tcl:") until you have a chance to read C. Tcl (and perhaps some of the Tcl references recommended there).
An important reference for these examples, even if you are familiar with Tcl, is the GUI Tcl Library reference available online from Help>Manuals contents>Tornado API Reference. It describes the building blocks for the user interface (GUI) shared by the Tornado tools. |
||||||||||||||||||
All Tornado tools can be altered to your needs (and to your taste) by adding your own Tcl code. This section has a few examples of launcher customization.
When you consider modifications to the launcher, you may want to read related code in the standard form of the launcher. The Tcl code implementing the launcher is organized as follows:
When the launcher starts up, it looks for a file called .wind/launch.tcl in your home directory. If that file is present, its contents are read with the Tcl source command before the launcher puts up its initial display. Use this file to collect your custom modifications, or to incorporate shared customizations from a central repository of Tcl extensions at your site.
When you begin experimenting with any new system (or language), errors are to be expected. Any error messages from your launcher Tcl initialization code are captured by the launcher, and a summary of the error is displayed in a window similar to Figure 3-5.
To see the full Tcl error display, click on the Details button in the error display; click Continue to dismiss the display.
The examples in this section use the Tcl extensions summarized in Table 3-2. For detailed descriptions of these and other Tornado graphical building blocks in Tcl, see Help>Manuals contents>Tornado API Reference>GUI Tcl Library.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Because the launcher has no direct command-line access to Tcl, it is not as convenient as other tools (such as WindSh or CrossWind) for experimentation with Tcl extensions. The following example makes things a little easier: it adds a command to the File menu that reloads the .wind/launch.tcl file. This avoids having to Quit the launcher and invoke it again, every time you change launcher customization.
Example 3-1: Tcl Reinitialization
# "Reinitialize" command for Launcher.
# Adds item to File menu; calls Tcl "source" primitive directly.
menuButtonCreate File "Re-Read Tcl" T {
source ~/.wind/launch.tcl
}
When you select the Quit command from the launcher File menu, the launcher displays the short form shown in Figure 3-6 to make sure you selected Quit intentionally.
This sort of safeguard is nearly universal in graphical applications, but some people find it annoying. If you would prefer to take your chances with an occasional unintended shutdown, for the sake of having the launcher obey you unquestioningly, this example may be of interest. It shows how to redefine the Quit command to shut down the launcher without first displaying a query.
To discover what procedure implements the Quit command, examine the launcher definitions in installDir/host/resource/tcl/Launch.tcl. Searching there for the string "Quit" leads us to the following menuButtonCreate invocation, which shows that the procedure to redefine is called launchQuit:
menuButtonCreate File Quit Q {launchQuit}
Example 3-2: Alternate Quit Definition
The following redefinition of the launchQuit procedure eliminates the safeguard against leaving the launcher accidentally:
############################################################################## # launchQuit - abandon the launcher immediately # # This routine is a replacement for the launchQuit that comes with the # launcher; it runs when Quit is selected from the File menu in place of # the standard launchQuit, to avoid calling a confirmation dialog. # # SYNOPSIS: # launchQuit # # RETURNS: N/A # # ERRORS: N/A #
proc launchQuit {} {
exit
}
Because editing files is a common development activity, it may be useful to invoke an editor from the launcher. This example defines a File>Open command to run the editor specified by the EDITOR environment variable. The example is based on the file selector built into the noticePost Tcl extension.
The code in this example collects the launcher initialization (adding commands to the File menu, both for this example and for Example 3-1) in an initialization procedure as recommended in D. Coding Conventions. In the example, the launcher executes launchExtInit, which adds entries to the File menu. Of these two new entries, Open calls launchFileOpen, which in turn calls launchEdit if the user selects a file to open.
Example 3-3: Open Command and Customized File Menu Initialization
############################################################################## # # launchExtInit - collects personal launcher initialization # # This routine is invoked when the launcher begins executing, and collects # all the initialization (other than global and proc definitions) # defined in this file. # # SYNOPSIS: # launchExtInit # # RETURNS: N/A # # ERRORS: N/A #
proc launchExtInit {} {
# "Reinitialize" command for Launcher.
# Adds item to File menu; calls Tcl "source" primitive directly.
menuButtonCreate File "Re-Read Tcl" T {
source ~/.wind/launch.tcl
}
# Add "Open" command to File menu
menuButtonCreate File "Open..." O {
launchFileOpen ;# defined in launch.tcl
}
}
############################################################################## # # launchFileOpen - called from File menu to run an editor on an arbitrary file # # This routine supports an Open command added to the File menu. It prompts # the user for a filename; if the user selects one, it calls launchEdit to # edit the file. # # SYNOPSIS: # launchFileOpen # # RETURNS: N/A # # ERRORS: N/A #
proc launchFileOpen {} {
set result [noticePost fileselect "Open file" Open "*"]
if {$result != ""} {
launchEdit $result
}
}
############################################################################## # # launchEdit - run system editor on specified file # # This routine runs the system editor (as specified in the environment # variable EDITOR, or vi if EDITOR is undefined) on the file specified # in its argument. # # SYNOPSIS: # launchEdit fname # # PARAMETERS: # fname: the name of a file to edit # # RETURNS: N/A # # ERRORS: N/A #
proc launchEdit {fname} {
# we need to examine environment variables
global env
if { ([file readable $fname] && ![file isdirectory $fname]) ||
([file writable [file dirname $fname]] && ![file exists $fname])
} then {
# We have an editable file
# Use the EDITOR environment variable, with vi default
if [info exists env(EDITOR)] {
set editor $env(EDITOR)
} else {
set editor vi
}
if [string match "emacsc*" $editor] {
# looks like emacsclient. Don't run an xterm; just put this
# in the background.
exec $editor $fname &
} else {
# Run an xterm with the editor in it.
exec xterm -e $editor $fname &
}
} else {
# fname was unreadable or a directory
noticePost info "Cannot open: <<$fname>>"
}
}
############################################################################## # # launch.tcl - initialization for private extensions to launcher # # The following line executes when the launcher begins execution; it # calls all private launcher extensions defined in this file. #
launchExtInit
1: By default the launcher has the registry create its database in installDir/.wind. If that directory is not writable, the database is created in homeDir/.wind.
2: If you have any trouble with this command, make sure that your host development environment is correctly configured, as described in 2.3 The Tornado Host Environment.
3: Tornado includes a version of the VxSim target simulator that runs as a single instance per user, without networking support (optional products such as VxMP are not available for this version). The full-scale version supports multiple-instance use and includes networking support. It is available as an optional product.
4: Tornado includes a version of WindView designed solely for use with the VxWorks target simulator. WindView is also available as an optional product for all supported target architectures.
5: You can also restrict your target servers to permit connections only by a particular list of users; see 3.5.2 Sharing and Reserving Target Servers.
6: Data for each saved configuration is stored in a file with the same name as the configuration, in the directory .wind/tgtsvr under your home directory.
7:
You can also create a virtual console from any Tornado tool using Tcl, with
wtxConsoleCreate. See the online Tornado API Reference: WTX TCL API.
8: To disable the automatic display of log files by the launcher, insert "set noViewers 1" in your ~/.wind/launch.tcl initialization file.
9: Strictly speaking, there is another layer of authorization defining who is meant by "any user". The file installDir/.wind/userlock is a Tornado-wide authorization file, used as the default list of authorized users for any target server without its own authorized-users file. The format of this file is the same format described below for individual target-server authorization files.
10: The editor specified in your EDITOR environment variable, or vi.