---

3    Creating Subset Control Programs

A subset control program can perform all of these tasks. Layered product kits designed according to the guidelines in Chapter 2 must have subset control programs to create the required links.

This chapter describes how to write subset control programs for layered products.

---

3.1    Common Characteristics of a Subset Control Program

---

3.1.1    Creating Subset Control Program Source Files

Place all subset control programs that you write in the scps directory, a subdirectory of the data directory. The subset control program's file name must match the subset name to which it belongs, and it must end with the scp suffix. For example, the ODB product defines two subsets, named OATODB100 and OATODBDOC100. If both subsets required a subset control program, the source file names would be OATODB100.scp and OATODBDOC100.scp.

When you create the subsets as described in Chapter 4, the kits utility copies the subset control programs from the scps directory to the instctrl directory. If a subset has no subset control program, the kits utility creates an empty subset control program file for it in the instctrl directory.

---

3.1.2    Including Library Routines

. /usr/share/lib/shell/libscp

---

3.1.3    Invoking Subset Control Programs

Figure 3-1 shows time lines of the setld utility when invoked with the -l, -d, and -v options. The actions that setld takes are written above the lines; the value of the ACT environment variable and the actions that the subset control program takes at each phase are written below the lines.

When it enters a new phase, the setld utility sets the ACT environment variable to a value that corresponds to the phase, then it invokes your subset control program. The subset control program checks the value of the environment variable to determine what action it needs to take. In some cases, setld also passes arguments to the subset control program. The subset control program uses the argument values to further determine the actions it needs to take.

Do not include a wildcard in your subset control program's option-parsing routine; write code only for the cases the subset control program actually handles. For example, the subset control programs in this chapter provide no code for several conditions under which they can be invoked. The case statements that choose an action simply exit with zero status in these undetected cases, and setld continues.

Figure 3-1: Time Line of the setld Utility

---

---

3.1.4    Aborting the Program

---

3.1.5    Setting Global Variables

You can call the STL_ScpInit routine to define these variables and initialize them to their values for the current subset. This routine eliminates the need to hard code subset information in your subset control program. Use STL_ScpInit in all phases except the M phase to initialize global variables. All variable names begin with an underscore (_) for easy identification.

---

3.1.6    Working in a Dataless Environment

Checks to see if a subset is being installed into a dataless environment.

STL_NoDataless

Declines installation of a subset into a dataless environment.

---

3.2    Tasks Associated with Installation Phases

---

3.2.1    Displaying the Subset Menu (M Phase)

For example, during this phase the subset control program can issue the machine command to verify that the subset is being installed on the correct hardware platform. If the command returns a nonzero status, the subset control program exits with a nonzero status.

When setld extracts a subset into a RIS server's product area, the server also executes the subset control program to make use of the program's code for the M phase of installation. You should code the M phase to detect the difference between extraction of the subset into a RIS area and loading of the subset for use of its contents. To make this determination, check the value of the $1 command argument (either -x for RIS extraction or -l for loading). For RIS extraction, the subset control program should do nothing during the M phase. When loading subsets, it should make this machine test.

The following Bourne shell example illustrates one way to code the M phase. The subset control program checks to see if it is running on Digital's Alpha processor.

case $ACT in
  M)
    case $1 in
      -l)
        [ "`/bin/machine`" = alpha ] || exit 1
        ;;
    esac
    ;;

.
.
.

esac

---

3.2.2    Before Loading the Subset (PRE_L Phase)

The subset control program should also check for subset dependencies at this time. A subset dependency is a condition under which a subset depends on the existence of one or more other subsets. Because setld can both install and remove subsets, the system administrator could attempt to remove one or more subsets on which your product depends. Because those subsets do not in turn depend on your product's subsets, setld usually removes them without question, leaving your product disabled. You can prevent this inadvertent destruction of your product's environment by locking the subsets on which your subset depends. Subset locking can occur during the POST_L phase (see Section 3.2.3.3).

To make dependency management easier to implement, Digital provides a set of routines in the form of Bourne shell script code. These routines are in the file /usr/share/lib/shell/libscp.

The dependency management routines use dependency expressions to examine conditions on the system. A dependency expression is a postfix logical expression that describes the conditions on which the subset depends. Dependency expressions are recursive left to right and processed using conventional postfix techniques. Dependency expressions are defined in Backus-Naur form, as follows:

depexp ::= wc_subset_id
        |  depexp not
        |  depexp depexp and
        |  depexp depexp or

Represents a subset identifier that can contain file name expansion characters (asterisks, question marks, or bracketed sets of characters) as in OAT[RV]DOA*2??.

and operator

Requires two dependency expressions. The dependency is satisfied if both expressions are satisfied.

or operator

Requires two dependency expressions. The dependency is satisfied if at least one of the expressions is satisfied.

not operator

Requires one dependency expression. The dependency is satisfied if the expression is not satisfied.

The following are valid dependency expressions:

SUBSETX??0
SUBSETY200 not
SUBSET[WX]100 SUBSETY200 and
SUBSETX100 SUBSETY200 or
SUBSETX100 SUBSETY200 and SUBSETZ300 or not

Establishes objects that the STL_DepEval routine uses. Before you use STL_DepEval to check your subset's dependencies, you must execute STL_DepInit once. This routine has no arguments and returns no status.

STL_DepEval depexp

Evaluates the dependency expression that you specify as an argument. You can use as many invocations of STL_DepEval as you need to verify that all your subset dependencies are met.

---

3.2.3    After Loading the Subset (POST_L Phase)

As indicated in Chapter 2, a layered product's files should be installed in the /usr/opt and /var/opt areas and accessed by means of symbolic links in the standard UNIX directory structure, such as /usr/bin. These symbolic links, referred to as forward links, must be created during the POST_L phase, after the referent files are in place. Do not try to create these links during the C INSTALL phase because the /usr file system is not guaranteed to be writeable at that time. If your product includes links in /var, create these links also in POST_L. To maintain symmetry, you must remove links during the PRE_D phase, not during the C DELETE phase.

Symbolic links for layered products are usually created in the standard UNIX directories to refer to files that are actually in the layered product areas /usr/opt and /var/opt. These links are relatively straightforward.

Sometimes you may need to create links within your product's directories in the layered product areas that refer to files in the standard hierarchy. Such backward links must be created carefully because the layered product directories can themselves be symbolic links. This means that you cannot rely on knowing in advance the correct number of directory levels (../) to include in the ln commands for your backward links. For example, /var is frequently a link to /usr/var.

When a kit is installed on an NFS server, all the backward links are made in the server's kit area. Then, when that area is exported to clients, the links are already in place for the client. You do not need to create any backward links in the client area.

Note

NFS clients importing products with backward links must have directory hierarchies that exactly match those on the server. Otherwise, the backward links fail.

---

3.2.3.1    Creating Forward Links

Any nonempty directories in the inventory should leave the link bit unset (set to 0) to maximize the performance of STL_LinkCreate. See Example 3-2 for a subset control program that creates and removes symbolic links.

The following routines create forward links:

STL_LinkInit

Used in the POST_L phase to establish internal variables for the STL_LinkCreate routine. Before you use STL_LinkCreate to create a link, you must execute STL_LinkInit once. This routine has no arguments and returns no status.

STL_LinkCreate

Creates forward links from the installed system to the product areas, such as the /opt areas. Call STL_ScpInit first to initialize required global variables. A forward link from the system to the product areas (under /usr/opt or /var/opt) is created for each file whose link flag is set in the master inventory file. For example, the link bit of the ./usr/opt/OAT100/bin/attr file is set as follows in the master inventory file:

    4        ./usr/opt/OAT100/bin/attr               OATODB100

---

3.2.3.2    Creating Backward Links

Use the STL_LinkInit and STL_LinkBack routines to create backward links as follows, and use the rm shell command to remove them:

STL_LinkInit

Used in the POST_L phase to establish internal variables for the STL_LinkBack routine. Before you use STL_LinkBack to create a link, you must execute STL_LinkInit once. This routine has no arguments and returns no status.

STL_LinkBack link_file file_path link_path

Creates a valid symbolic link from your product area (under /usr/opt or /var/opt) to a directory within the standard UNIX directory structure. You can use STL_LinkBack repeatedly to create as many links as required. link_file is the name of the file to link; file_path is the dot-relative path of the directory where the file actually resides; and link_path is the dot-relative path of the directory where you should place the link. This routine returns no status.

Example 3-1 uses STL_LinkInit and STL_LinkBack in the POST_L phase to create a link named /usr/opt/OAT100/lib/odb_users that refers to the real file /etc/odb_users, and removes the link in the PRE_D phase.

#! /sbin/sh

case $ACT in

.
.
.

  POST_L)
    STL_LinkInit
    STL_LinkBack odb_users ./etc ./usr/opt/OAT100/lib
    ;;

  PRE_D)
    rm -f ./usr/opt/OAT100/lib/odb_users
    ;;
esac

---

3.2.3.3    Locking Subsets

Used in the POST_L and PRE_D phases to establish objects for the STL_DepLock and STL_DepUnLock routines. Before you use STL_DepLock or STL_DepUnLock to manipulate subset locks, you must execute STL_LockInit once. Because locking and unlocking are managed by different invocations of your subset control program, STL_LockInit must appear in both the POST_L and PRE_D phases. You should code two instances of STL_LockInit rather than calling it once before you make a decision based on the value of the ACT environment variable. This routine has no arguments and returns no status.

STL_DepLock subset depexp ...

Used in the POST_L phase to add the new subset's name to the lock lists for each of the subsets named as arguments. (You can use dependency expressions as arguments.) The name of the new subset is the first argument to STL_DepLock. For example, the following call to STL_DepLock places OATODB100 in the OATTOOLS100.lk and OATBASE2??.lk files:

    STL_DepLock OATODB100 OATTOOLS100 OATBASE2??

---

3.2.4    After Securing the Subset (C INSTALL Phase)

---

3.2.5    Verifying the Subset (V Phase)

---

3.2.6    Before Deleting a Subset (C DELETE Phase)

---

3.2.7    Before Deleting a Subset (PRE_D Phase)

Removes links created by STL_LinkCreate and restores any original files that STL_LinkCreate saved. Call STL_ScpInit first to initialize required global variables. The STL_LinkRemove routine cannot remove modified links.

STL_DepUnLock subset depexp ...

Removes the new subset's name from the lock lists for each of the subsets named as arguments.

---

3.2.8    After Deleting a Subset (POST_D Phase)

---

3.3    Subset Control File Flag Bits

FLAGS=34816

#! /sbin/sh

. /usr/share/lib/shell/BitTest

flags=`sed -n '/FLAGS=/s///p' usr/.smdb./OATODBDOC100.ctrl`
BitTest $flags 11 && {

.
.
.

}

---

3.4    User Product Subset Control Program

• During the PRE_L phase, performs dependency checking to make sure the base tools are already installed.

• During the POST_L phase, creates symbolic links and locks subsets on which it depends.

• During the C INSTALL phase, notifies the user that installation is complete.

• During the PRE_D phase, removes symbolic links.

• During the POST_D phase, unlocks subsets.

The program does not handle the V phase or the C DELETE phase. When setld invokes the program at these times, the program simply exits with a success status.

#!/sbin/sh
#
# Subset Control Program for OATODB??? subset

# INCLUDE SCP LIBRARY FUNCTIONS

[ `/bin/machine` = alpha ] &&
    . /usr/share/lib/shell/libscp [1]

# BEGIN EXECUTION HERE

case $ACT in [2]

M) [3]
    case $1 in
    -l)
        # hardware platform check
        [ "`./bin/machine`" = alpha ] || exit 1
        ;;
    esac
    ;;

PRE_L) [4]
    # dependency checking
    STL_ScpInit
    STL_DepInit

    STL_DepEval ${_PCODE}TOOLS??? ||
    {
        _OOPS="$_OOPS
    Orpheus Authoring Tools (${_PCODE}TOOLS)"
    }

    STL_DepEval ${_PCODE}BASE[2-9]?? ||
    {
        _OOPS="$_OOPS
    Orpheus Authoring Base Tools, Version 2.0 or later (${_PCODE}TOOLS)"
    }

    [ "$_OOPS ] &&
    {
        echo "
The $_DESC requires the existence of
the following uninstalled subset(s):
$_OOPS

Please install these subsets before retrying the installation.
" >&2
        exit 1
    }
    ;;
POST_L) [5]
    # create symbolic links
    STL_ScpInit
    STL_LinkCreate

    # dependency locking
    STL_LockInit
    STL_DepLock $_SUB ${_PCODE}TOOLS??? ${_PCODE}BASE[2-9]?? and
    ;;
C) [6]
    STL_ScpInit
    case $1 in
    INSTALL)
        echo "
Installation of the $_DESC ($_SUB)
subset is complete.

Before using the tools in this subset, please read the README.odb
file located in the /usr/lib/br directory for information on the
kit's contents and for release information.
"
        ;;
    esac
    ;;
PRE_D) [7]
    # remove symbolic links
    STL_ScpInit
    STL_LinkRemove

    # dependency unlocking [8]
    STL_LockInit
    STL_DepUnLock $_SUB ${_PCODE}TOOLS??? ${_PCODE}BASE[2-9]?? and
    ;;

esac

exit 0  [9]

1. --> Reads in the subset control program library routines if the installation is running on an Alpha platform.

2. --> Examines the ACT environment variable to select the action the subset control program takes when called by setld.

3. --> For the M phase, if the installation is running on an Alpha platform, allows setld to continue. If not, the subset control program returns a nonzero status and exits. As a result, setld does not present this subset in its menu of subsets to be installed.

4. --> During the PRE_L phase, ensures that subsets on which the OATODB100 subset depends are installed. If they are not installed, the subset control program describes the missing subsets and returns a nonzero status to setld, which aborts the installation of this subset. If multiple subsets are being installed, each is treated individually. The $_PCODE, $_OOPS, and $_DESC variables are defined by the STL_ScpInit routine.

5. --> During the POST_L phase, creates symbolic links from the subset by invoking the STL_ScpInit and STL_LinkCreate routines. After creating the links, the subset control program secures the subset by locking the subsets on which it depends to ensure that they are not deleted without warning the user of potential problems. The subset control program uses the $_SUB and $_PCODE global variables to define the subsets in the dependency relationship.

6. --> During the C phase, checks to see if the argument passed in by setld has the value of INSTALL. If so, the program displays a message indicating that the installation is complete. It uses STL_ScpInit and global variables to substitute the product description ($_DESC) and subset ID ($_SUB) within the message text.

7. --> During the PRE_D phase, calls the STL_ScpInit and STL_LinkRemove routines to remove the symbolic links that STL_LinkCreate created during the POST_L phase.

8. --> Calls the STL_LockInit and STL_DepUnLock routines to unlock the subsets on which OATODB100 depends. The $_SUB variable is defined by the STL_ScpInit routine.

9. --> Ensures that the subset control program returns a success status to setld for each successful action and for all of the possible cases that the subset control program does not handle. Do not code exit 0 statements elsewhere in your subset control program.

---

3.5    Kernel Product Subset Control Program

• Write one subset control program for a kit that contains the software subset associated with the single binary module for a statically configured driver.

• Write one subset control program for a kit that contains the software subset associated with the single binary module for a dynamically configured driver.

• Write one subset control program for a kit that contains the software subsets associated with the device driver that can be statically or dynamically configured.

Example 3-3 shows the subset control program for the single binary module associated with the /dev/none driver. The user can choose to configure this single binary module into the kernel either statically or dynamically. The subset control program runs the doconfig utility to configure the driver into the kernel.

#!/sbin/sh
#
#
#  NONE.scp - Install the files associated with the /dev/none
#  device driver.  This driver, implemented as a single binary
#  module (.mod file), can be statically or dynamically configured
#  into the kernel.
#

case "$ACT" in [1]
C)
    case $1 in
    INSTALL)  [2]
        echo "***** /dev/none Product Installation Menu *****"
        echo "*****                                     *****"
        echo "1. Install the static device driver subset."
        echo "2. Install the dynamic device driver subset."

        echo" Type the number for your choice [] "

        read answer
        case ${answer} in
            1)  [3]
            # Register the files associated with the static
            # /dev/none device driver product.
            kreg -l EasyDriverInc ESANONESTATIC100 /usr/opt/ESA100 [4]

            # Add the files associated with the statically configured
            # /dev/none device driver product to the customer's
            # /etc/sysconfigtab database
            sysconfigdb -a -f /usr/opt/ESA100/sysconfigtab none [5]

            echo "The rest of the procedure will take 5-15 minutes"
            echo "to rebuild your kernel, depending on the processor"
            echo "type."
            echo ""
            echo "Starting kernel rebuild... "
            if doconfig -c $HOSTNAME [6]
                then
                echo "Kernel built successfully"
            else
                1>&2 echo "Error building kernel."
                return 1 
            fi
            ;;

            2)  [7]
            # Add the files associated with the dynamically configured
            # /dev/none device driver product to the customer's
            # /etc/sysconfigtab database
            sysconfigdb -a -f /usr/opt/ESA100/sysconfigtab none [8]

            # Copy the none.mod file to the /subsys directory. Create
            # the none.mth driver method by linking to device.mth
            # /subsys/none.mth -> /subsys/device.mth
            cp /usr/opt/ESA100/none.mod /subsys/none.mod [9]
            ln -s /subsys/device.mth /subsys/none.mth [10]

            # Load the /dev/none device driver and create the device
            # special files
            sysconfig -c none [11]

            echo "The /dev/none device driver was added to your
            echo "/etc/sysconfigtab database." [12]
            ;;
        esac
        ;;

    DELETE) [13]
        echo "***** /dev/none Product Installation Menu *****"
            echo "*****                                 *****"
        echo "1. Delete the static /dev/none device driver subset."
        echo "2. Delete the dynamic /dev/none device driver subset."

        echo" Type the number for your choice [] "

        read answer
        case ${answer} in
            1)
            kreg -d ESANONESTATIC100 [14]

            # Delete the /dev/none device driver's entry from the
            # /etc/sysconfigtab database

            sysconfigdb -d none [15]
            echo "The rest of the procedure will take 5-15 minutes"
            echo "to rebuild your kernel, depending on the processor"
            echo "type."
            echo ""
            echo "Starting kernel rebuild... "
            if doconfig -c $HOSTNAME [16]
                then
                echo "Kernel built successfully"
            else
                1>&2 echo "Error building kernel."
                return 1 
            fi
            ;;

            2)
            # Make sure the /dev/none device driver is not currently
            # loaded
            sysconfig -u none  [17]

            # Delete the /dev/none device driver's entry from the
            # /etc/sysconfigtab database
            sysconfigdb -d none [18]
             ;;
        esac
        ;;
    esac
    ;;
esac
exit 0

1. --> Examines the ACT environment variable to select the action the subset control program should take.

2. --> During the C INSTALL phase, displays a menu of installation options. The user can choose to install the driver for static configuration or dynamic configuration.

3. --> If the user chooses menu item 1, performs a static configuration.

4. --> Invokes the kreg utility to register the driver files with the kernel. The kreg utility registers a device driver product by creating the /usr/sys/conf/.product.list file on the customer's system. This file contains registration information associated with the static device driver product. The subset control program calls kreg with the following arguments:

   • The -l flag

     This flag indicates that the subset was loaded, and it directs kreg to register the device driver product as a new kernel extension.

   • Company name

     The company name is EasyDriverInc. The kreg utility places this name in the company name field of the customer's /usr/sys/conf/.product.list file.

   • Software subset name

     The software subset name for this device driver product is ESANONESTATIC100. The subset name consists of the product code, subset mnemonic, and 3-digit version code. The kreg utility extracts information from the specified subset data and loads it into the customer's /usr/sys/conf/.product.list file.

   • Directory name

     The directory on the customer's system where kreg copies the files associated with this driver product is /usr/opt/ESA100. The kreg utility places this directory in the driver files path field of the customer's /usr/sys/conf/.product.list file.

5. --> Adds the sysconfigtab file fragment for the statically configured driver to the system's /etc/sysconfigtab database by calling the sysconfigdb utility with the following arguments:

   • The -a flag

     This flag causes sysconfigdb to add the device driver entry to the customer's /etc/sysconfigtab database.

   • The -f flag

     This flag precedes the name of the sysconfigtab file fragment whose device driver entry is to be added to the /etc/sysconfigtab database. This flag is used with the -a flag.

   • The sysconfigtab file fragment

     The kit developer at EasyDriver, Inc. specifies the path /usr/opt/ESA100/sysconfigtab to indicate the location of the sysconfigtab file fragment for the /dev/none device driver.

   • Device driver name

     The kit developer at EasyDriver, Inc. specifies none as the name of the driver whose associated information is added to the /etc/sysconfigtab database. This name is obtained from the entry_name item of the sysconfigtab file fragment, as described in Writing Device Drivers: Tutorial.

6. --> Runs the doconfig utility to configure the driver into the kernel. The subset control program returns an error if doconfig fails for any reason.

7. --> If the user chooses menu item 2, performs a dynamic configuration.

8. --> Calls sysconfigdb to add the driver's sysconfigtab file fragment to the system's /etc/sysconfigtab database.

9. --> Copies the dynamically configured driver's single binary module (.mod file) to the /subsys directory.

10. --> Creates a symbolic link from the /subsys/device.mth file to the driver's /subsys/none.mth file.

11. --> Calls the sysconfig utility with the -c option to reconfigure the system and include the /dev/none driver. The -c option causes the sysconfig utility to dynamically configure the driver into the running system and to create device special files. The name of the driver as specified in the sysconfigtab file fragment follows the option.

12. --> Displays a message notifying the user that the driver has been added to the system.

13. --> During the C DELETE phase, displays a menu of options for deleting subsets. The user must tell the setld utility whether the subset to be deleted represents a statically configured driver or a dynamically configured driver. The way the driver was configured determines how the driver is deleted.

14. --> If the user chooses menu option 1 (delete a statically configured driver), calls the kreg utility to deregister the driver with the kernel. When the kreg utility is called with the -d flag, it deletes the entry for the specified layered product from the customer's /usr/sys/conf/.product.list file. In this case, the layered product is the /dev/none driver, represented by the ESANONESTATIC100 subset identifier.

15. --> Calls the sysconfigdb utility with the -d flag, which deletes the static /dev/none device driver from the customer's /etc/sysconfigtab database.

16. --> Runs the doconfig utility to reconfigure the kernel. The subset control program returns an error if doconfig fails for any reason.

17. --> If the user chooses menu item 2 (delete a dynamically configured driver), calls the sysconfig utility with the -u flag to unconfigure the dynamically configured /dev/none device driver from the running system.

18. --> Calls the sysconfigdb utility with the -d flag to delete the dynamically configured /dev/none device driver from the customer's /etc/sysconfigtab database.

---

3.6    Foreign Device Subset Control Program

The RIS utility provides the ability to install kits into a RIS area for subsequent installation on a client system. When installing the kit into a RIS area, the RIS installation procedure calls the subset control program, passing EXTRACT as an argument. The RIS utility, not the setld utility, defines this phase. The subset control program must set the ACT environment variable to EXTRACT in this situation.

The RIS utility invokes the subset control program at the end of the extract procedure when installing the kit on a RIS server. During this phase, the subset control program needs to invoke the kreg utility to register the new product with the kernel so that the driver is properly installed when the RIS server builds a new install kernel. In addition, the subset control program invokes the sysconfigdb utility to modify the /etc/sysconfigtab database. The modifications to the server by kreg and sysconfigdb occur only in the RIS area, as opposed to the server's root directory.

The /etc/sysconfigtab database created during this phase of the subset control program is copied onto the client system as part of the installation. This copy replaces the /etc/sysconfigtab database installed as part of the base operating system subset load. This ensures that the proper support for the driver exists on the system.

The setld utility calls the subset control program during the C INSTALL phase when performing a network installation of RIS clients. At this time, the subset control program calls the kreg utility to register the driver with the new system. This adds the driver into the kernel that is built as part of the installation process. No modification to the /etc/sysconfigtab database is required at this point because the installation process takes care of the required modification during the EXTRACT phase.

A kit for a foreign device may be installed by osfboot or by the RIS utility during bootstrap linking of the kernel. The subset control program in Example 3-4 supports both types of installation. The subset control program does not provide a menu of configuration options because a driver for a foreign device must be statically configured.

#!/sbin/sh
#
#
#  EDGD.scp - Install files associated with the statically
#             configured /dev/edgd device driver product.
#
#

#
# RIS server installation of a foreign kit
#
# In the case of RIS extract, the variable ACT is NULL, and
# the first parameter passed to the subset control program
# specifies the phase.
#
[ "$ACT" ] ||  [1]
    ACT=$1

case "$ACT" in

#
# Configuration INSTALL phase takes place after the subsets
# are loaded.  This phase configures the device driver into
# the system.  It is invoked on all installations of the kit
# during CD-ROM or RIS-client Digital UNIX installation, and
# setld -l on an installed system.
#
C)
    case $1 in
    INSTALL) [2]
        echo "INSTALL phase "

        # Register the files associated with the static
        # /dev/edgd device driver product.
        kreg -l EasyDriverInc EDGSTATIC100 /usr/opt/EDG100 [3]

        # Add the sysconfigtab file fragment associated with the
        # static /dev/edgd device driver product to the customer's
        # /etc/sysconfigtab database.
        sysconfigdb -a -f /usr/opt/EDG100/sysconfigtab edgd [4]
        ;;
    esac
    ;;

#
# RIS server kit installation phase
#
EXTRACT)  [5]

    echo "EXTRACT phase "

    #
    # The RIS server does this with ROOT set to the RIS area,
    # and the RIS area must be extracted, not linked to a CD-ROM.
    #

    # Register the files associated with the static /dev/edgd
    # device driver product.
    kreg -l EasyDriverInc EDGSTATIC100 /usr/opt/EDG100 [6]

    # Break link between /etc/sysconfigtab and /etc/.new..sysconfigtab
    # so the subset control program can run sysconfigdb for the RIS
    # installation.
    rm /etc/sysconfigtab  [7]

    # Copy the /etc/sysconfigtab database to client system.
    cp /etc/.new..sysconfigtab /etc/sysconfigtab [8]

    # Add the files associated with the static /dev/edgd device
    # driver product to the customer's /etc/sysconfigtab database.
    sysconfigdb -a -f /usr/opt/EDG100/sysconfigtab edgd [9]
    ;;

#
#  This phase is executed on a setld -d command, which removes
#  the subset from the system.
#
POST_D)  [10]

    kreg -d EDGSTATIC100    [11]
    rm -rf /usr/opt/EDG100  [12]
    sysconfigdb -d  edgd    [13]

    echo "The /dev/edgd device driver is no longer on the system." [14]
    echo "Remember to build a new kernel by running doconfig to"
    echo "remove the /dev/edgd driver functionality."
    ;;

esac
exit 0

1. --> If ACT is null, sets the environment variable to the value of the first argument. The ACT environment variable is null during the RIS extract phase, when the RIS utility calls the subset control program with an argument of EXTRACT.

2. --> Handles the C INSTALL phase when the device driver is configured into the system.

3. --> Invokes the kreg utility to register the driver files with the kernel. The kreg utility registers a device driver product by creating the /usr/sys/conf/.product.list file on the customer's system. This file contains registration information associated with the static device driver product. The subset control program calls kreg with the following arguments:

   • The -l flag

     This flag indicates that the subset was loaded, and it directs kreg to register the device driver product as a new kernel extension.

   • Company name

     The company name is EasyDriverInc. The kreg utility places this name in the company name field of the customer's /usr/sys/conf/.product.list file.

   • Software subset name

     The software subset name for this device driver product is EDGSTATIC100. The subset name consists of the product code, subset mnemonic, and 3-digit version code. The kreg utility extracts information from the specified subset data and loads it into the customer's /usr/sys/conf/.product.list file.

   • Directory name

     The directory on the customer's system where kreg copies the files associated with this driver product is /usr/opt/EDG100. The kreg utility places this directory in the driver files path field of the customer's /usr/sys/conf/.product.list file.

4. --> Adds the sysconfigtab file fragment for the statically configured driver to the system's /etc/sysconfigtab database by calling the sysconfigdb utility with the following arguments:

   • The -a flag

     This flag causes sysconfigdb to add the device driver entry to the customer's /etc/sysconfigtab database.

   • The -f flag

     This flag precedes the name of the sysconfigtab file fragment whose device driver entry is to be added to the /etc/sysconfigtab database. This flag is used with the -a flag.

   • The sysconfigtab file fragment

     The kit developer at EasyDriver, Inc. specifies the path /usr/opt/EDG100/sysconfigtab to indicate the location of the sysconfigtab file fragment for the /dev/edgd device driver.

   • Device driver name

     The kit developer at EasyDriver, Inc. specifies edgd as the name of the driver whose associated information is added to the /etc/sysconfigtab database. This name is obtained from the entry_name item of the sysconfigtab file fragment, as described in Writing Device Drivers: Tutorial.

5. --> During the EXTRACT phase, handles installation of the kit on the RIS server.

6. --> Invokes the kreg utility to register the driver files with the kernel. The kreg utility registers a device driver product by creating the /usr/sys/conf/.product.list file on the customer's system. This file contains registration information associated with the static device driver product.

7. --> Breaks the link to the /etc/sysconfigtab database on the client's system.

8. --> Copies the /etc/sysconfigtab database from the RIS area on the server to the client system.

9. --> Adds the sysconfigtab file fragment for the statically configured driver to the system's /etc/sysconfigtab database by calling the sysconfigdb utility with the -a and -f flags.

10. --> Handles the POST_D phase, when setld deletes the product subsets from the system.

11. --> Calls the kreg utility with the -d flag to deregister the driver with the kernel.

12. --> Removes the files from the product directory, EDG100, and any of its subdirectories, making the product unavailable on the system.

13. --> Calls the sysconfigdb utility with the -d flag to delete the device driver from the client's /etc/sysconfigtab database.

14. --> Displays a message on the console terminal informing the user that the device driver that controls the foreign device is no longer available on the system.