1    Introduction

A kit is a collection of files and directories that represent one or more layered products. A kit is a standard mechanism by which layered product modifications can be delivered and maintained on a Digital UNIX system. It can be distributed on a CD-ROM, diskette, or tape for installation on the customer's system with the setld utility. Finally, a kit can be presented to the Digital UNIX system at various times -- single-user time, multi-user time, installation time, or when setting up a RIS environment.

Before building a kit, you should consider the following questions:

• What kind of product does this kit represent? Does it run in user space or kernel space? Is it used during the initial installation and bootstrap of the Digital UNIX system?

• When will this kit be installed during the initial installation and boot of the system or after the system is up and running?

The answers to these questions determine the type of format you choose, the type of medium you use to distribute the kit, and the installation procedures that your users run when they install the kit on their systems.

This chapter can help you answer these questions. It describes the product types supported by the kit-building process and the options for packaging and installing the kit on the customer's system. It leads you through the steps involved in building kits for the various kinds of products, and it describes the installation options supported by the Digital UNIX system.

When you understand the kind of kit your are building, you can go to individual chapters of the book for detailed steps for building your particular kit.

1.1    Product Types

The kitting process described in this book lets you deliver layered products for the Digital UNIX system. A layered product is any software product that is not part of the base operating system. Layered products can fall into the following categories:

• User products

  These products run in user space. Commands and utilities fall into this category, as do applications such as text editors and database systems. Users interact directly with user products, for example, through commands or window interfaces.

• Kernel products

  These products run in kernel space. Users do not directly run kernel products, but the operating system and utilities access them to perform their work. For example, a device driver is one common type of kernel product. A user runs an application or utility, which generates system requests to perform operations such as opening a file or writing data to a disk. The system determines which device driver should service this request, then calls the appropriate driver interface.

• Foreign devices

  These are kernel products that may also be installed during the initial system installation and boot. Before a system manager can make use of the peripheral devices associated with foreign device controllers, the associated device drivers must be configured into the kernel. The problem is that prior to the installation of the operating system there is no kernel and no device drivers available to handle potential kernel and user requests of these foreign devices.

  The following are examples of hardware needed during the initial installation and boot of the operating system:

  • Hardware abstract layer (HAL)

    A HAL is a hardware interface that allows a given platform to operate within the Digital UNIX system. (Currently, HAL devices are not supported as foreign devices.)

  • Graphics controller

    A graphics controller is the hardware interface between the computer and a graphics terminal.

  • Disk controller

    A disk controller is the hardware interface between the computer and a disk device. (Currently, disk devices are not supported as foreign devices.)

  • Network controller

    A network controller (when booting from the network) is the hardware interface between the computer and a network device. (Currently, network controllers are not supported as foreign devices.)

1.2    Kit Formats

Prior to being copied onto the distribution media, the product files are gathered into subsets. Subsets group together related files and specify whether the group is required or optional for the installation procedure. You can choose to copy the product files onto the distribution media in one of the following formats:

• tar format

  In tar format, the product files belonging to the same subset are dumped to the distribution media as a single file. During installation, the setld utility uncompresses the files, then moves them onto the customer's system, preserving the files' original directory structure. The gentapes and gendisk utilities can create kits in tar format.

• Direct CD-ROM (DCD) format

  In DCD format, the files are written to the distribution media as a UNIX file system. Subsets distributed in DCD format cannot be compressed. The gendisk utility can create kits in DCD format.

User and kernel products should be produced in tar format; foreign device products must be produced in DCD format.

1.3    Kit-Building Process

Figure 1-1 illustrates the process of creating and packaging a kit for use with the setld utility. In the figure, dashed boxes represent optional steps; for example, you do not have to create subset control programs if your kit requires no special handling when it is installed. In the figure, the commands enclosed in ellipses perform the indicated steps of the kit-building process.
.Ne 27P

Figure 1-1: The Kit Building Process

The kit-building process is divided into the following steps:

1. Creating the directory structure containing the source files for the kit

   On the development system, you create a hierarchy of directories and files that represent the kit you want to build. The hierarchy has the following directory structure:

   • A source hierarchy contains all the files that make up the product.

   • A data hierarchy contains files needed to build the product. A master inventory lists all the product files and the subsets in which they belong. A key file identifies the product that the kit represents.

   • An output hierarchy holds the result of the kit-building process -- one or more subsets that make up the product kit.

   This directory structure is the same for user products, kernel products, and foreign device products. Only the contents of these directories differs among the product types. For example, a foreign device kit needs additional files that are unique to this specific kit type.

2. Creating a subset control program

   The setld utility can call a subset control program to perform installation steps specific to your kit. This program is optional for user products and kernel products. You supply it on your kit only if the product requires special installation steps. The program is required for RIS installations of foreign devices.

   Most layered products require an SCP, though the actions performed by the programs differ for each product type. For example, the SCP for a kernel kit may call the kreg utility, while the SCP for a user product would not.

3. Building subsets and control files

   Before transferring your kit onto distribution media, you organize the product files into subsets. Subsets group together related files. For example, one subset could contain optional product files, while another subset could contain the files required to run the product.

   The kits utility creates subsets according to the specifications you define in master inventory and key files. The newinv utility can help you maintain the master inventory.

4. Producing the distribution media

   When you have created the subsets for the product, you are ready to package the kit. At this point, you must decide whether to create the kit in DCD format or in compressed or uncompressed tar format. This is done by selecting the appropriate packaging utilities, such as gendisk or gentapes. If you are creating a kit for a foreign device product, you must also modify the kit and add files for the osfboot utility's boot-link support.

5. Installing the kit

   After you have successfully created the kit, you can test the installation. For user products and kernel products, you install the kit by running the setld utility. For foreign device products, you use the osfboot utility's boot-link technology to install the kit during the initial installation and bootstrap of the system and to build a custom kernel. You may also want to install the kit on a RIS server so that other users can install it across a network.

1.4    Sample Products

This book uses the following sample products to demonstrate how to build kits for each product type supported by Digital UNIX:

• Orpheus Document Builder (ODB)

  This application is one of a set of applications produced by the fictitious company, Orpheus Authoring Tools, Inc. This example shows how to build a kit for a user product.

• The /dev/none device driver

  This peripheral device driver is introduced in Writing Device Drivers: Tutorial. It is produced by the fictitious company, EasyDriver, Inc. This example shows how to build a kit for a kernel product.

• The /dev/edgd device driver

  This graphics driver is also introduced in Writing Device Drivers: Tutorial. It is a device driver produced by EasyDriver, Inc. This example shows how to build a kit for a foreign device product.