Different hosts may use interfaces for different purposes. For example, one host might use eth0 for local network communications and eth1 for powerline communications. Another host might do the opposite. A portability problem is created when scripts use the literal interface names on the command line, as illustrated below:
#!/bin/bash int6k -i eth1 -r int6k -i eth2 -r
The commands shown above will work on a host where eth1 and eth2 are used for powerline communications but will not work on another host where eth1 or eth2 are configured differently. Editing scripts can become a chore when they contain many interface references. One solution is the consistent use of symbols. For example, the following example provides some degree of portability.
#!/bin/bash
NIC1=eth1
NIC2=eth2
int6k -i ${NIC1} -r
int6k -i ${NIC2} -r
The commands shown above are an improvment because symbols NIC1 and NIC2 can be edited once; however, if you frequently move many scripts from one host to another then each script must be changed. That can also become a chore. A better solution is to define the symbols NIC1 and NIC2 once in a single file and then include the definitions in scripts that need them. For example, if we created file hardware.sh like so ...
#!/bin/bash # file: scripts/hardware.sh NIC1=eth1 NIC2=eth2
... then we could include it in one or more other scripts, like so ...
. ../scripts/hardware.sh
int6k -i ${NIC1} -r
int6k -i ${NIC2} -r
On Linux, the . command causes the named file to be included in-line as though it were part of the including file. This elminates the need to export symbol definitions. A full discussion of Linux environment variable scope can be found on the internet. The point is that each host should have it's own definitions files stored in a common folder so that other scripts can include them and reference them in a consistent manner.
Atheros example scripts include two definitions files: hardware.sh and firmware.sh. File hardware.sh defines hardware related symbols as shown below and file firmware.sh defines firmware and configuration filenames. They reside in a scripts folder and relative path is used to access them. This has proven to work well in most situations.
Example 6.1. hardware.sh
You should create a hardware.sh file in a common folder on each host where you want to execute toolkit scripts. In this way, a script created on one host can be executed on another host without modification.
#!/bin/bash # file: scripts/hardware.sh NIC1=eth1 NIC2=eth2 MAC1=00:50:04:A5:D9:5A MAC2=00:01:03:2B:03:67 DUT=eth1
File hardware.sh assigns specific values to symbols that are used in many of the scripts found in the scripts folder. Some Atheros scripts uses all these symbols and some do not. By convention, NIC1 and NIC2 name the Ethernet interfaces connected to a Golden Node and Device Under Test. MAC1 and MAC2 are the hardware addresses of NIC1 and NIC2, respectively. These symbols can be referenced in scripts with references like ${NIC1} or ${MAC1}. Of course, you could define other symbols here, as well. See the script under Device Upgrade as one example of how file hardware.sh can be included in another script.
Some scripts, such as flash.sh and upgrade.sh, only operate on one device and do not need to define both NIC1 and NIC2. By convention, these scripts reference interface DUT only.
Example 6.2. firmware.sh
You should create a firmware.sh file in a common folder on each host where you want to execute toolkit scripts. In this way, a script created on one host can be executed on another host without modification.
#!/bin/bash # file: scripts/firmware.sh CFG=sdram16mb.cfg CFG=sdram64mb.cfg PIB=v3.3.0.pib NVM=v3.3.0-0-5-A-FINAL.nvm NVM=v3.3.0-0-5-B-FINAL.nvm
File firmware.sh assigns specific filenames to symbols that are used in some of the scripts found in the scripts folder. Some Atheros scripts use all of these symbols and some do not. By convention, CFG defines the SDRAM configuration file used to initialize an INT6000™ or INT6300™ device, PIB defines the Parameter Information Block file to be used and NVM defines the firmware image file to be used.
This file is especially useful when working with a specific version of firmware. If there are multiple definitions for a symbol, the last definition is the one that takes effect. At Atheros, this file often contains dozens of definitions and we merely move or copy the ones we want to the end of the file. Our custom scripts then operate on the same configuration, parameter and firmware files until we reorder the definitions in firmware.sh.