5.2   Outlining the Example Problem

This chapter steps through the process of extending tool functionality. The example problem is in two parts: determine the status of all attached network interfaces, and display this information both with the Tornado shell (WindSh) and with the Tornado browser. Determining the network interface status requires that you create code to query the state of certain data structures on the target. The information needed is similar to that produced by the target shell routine ifShow( ). Once you extract the information, you can create a new host shell procedure that displays the information. After completing the shell implementation, you can add a new display to the Tornado browser as well.

To see what information is needed, review the output of the target shell ifShow( )routine.

-> ifShow 
dc (unit number 0): 
    Flags: (0x8063) UP BROADCAST RUNNING ARP MULTICAST  
    Type: ETHERNET_CSMACD 
    Internet address: 147.11.36.111  
    Broadcast address:   147.11.36.255 
    Netmask 0xffff0000 Subnetmask 0xffffff00 
    Ethernet address is 08:00:3e:24:dd:70 
    Metric is 0 
    Maximum Transfer Unit size is 1500 
    30954 packets received; 6 packets sent 
    30954 multicast packets received 
    5 multicast packets sent 
    0 input errors; 0 output errors 
    0 collisions; 0 dropped

To simplify this example, the network mask information is omitted (it is maintained in a different linked list); instead, the example focuses on the information that is directly available in the ifnet linked list of structures.

The solution is implemented through three files of Tcl code. The Tornado shell and browser share the Tcl code which gathers information from the target. The shell calls these information-gathering routines and then formats the output for printing. The browser uses these routines to supply graphical objects with data, providing a more interactive presentation of the same data. Figure 5-1 shows the directory location and relationship of the three elements.   

All Tcl-based Tornado tools have a directory in the resource hierarchy where you can place files of Tcl extension code: installDir/host/resource/tcl/app-config/toolName. When each tool starts, it reads all the extension files it finds in order1 . This means any extension to a tool can be packaged as a set of files which are inserted into the Tornado tree. The tools automatically read these files, allowing Tornado to be extended without modifying any of the existing files.

Since extension files are read in a specific order, a "patch" file can be inserted after an existing file to modify the behavior of an existing service (for example, by redefining a Tcl procedure found in the first file). To add a later modification that extends the NetShow extension you are creating, you might provide a file called 01NetShow2.tcl, which would be read immediately after 01NetShow.tcl.

The files located in installDir/host/resource/tcl are not automatically sourced. Include a source statement in any extension files that need to access this shared code.


*

CAUTION: During development, you may wish to place your working files in your homeDir/.wind directory. UNIX users can define the $HOME constant to be homeDir. Files in the $HOME/.wind directory are automatically sourced when you restart the tool, and this practice protects other Tornado users from any problems with your development code. Windows users will need to source the files. (For more information, see the Tornado User's Guide: Directories and Files.)


1:  Files are read in shell collating order (the same order that the files would be displayed by the ls( ) routine). This is why these files typically start with two numbers: so that new additions to this directory can be interleaved with existing files easily.