Host Independence
Prev | Chapter 6. Scripting | Next

## Host Independence

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`.

Prev | Up | Next
Linux Script Basics | Home | Checking Device Connection