1 Introduction

A kit is a collection of files and directories that represent one or more layered products. It is the standard mechanism by which layered product modifications are delivered and maintained on a Digital UNIX system. The kit can be distributed on a CD-ROM, diskette, or tape for installation on the customer's system. Finally, a kit can be installed on the Digital UNIX system at single-user time, multiuser time, installation time, or when setting up a Remote Installation Services (RIS) environment.

Before building a kit, consider the kind of product the kit represents:

Does it run in user space or kernel space?
Is it used during the initial installation and bootstrap of the Digital UNIX system?
Will it be integrated into a RIS environment?

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 helps 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 that the Digital UNIX system supports.

After you determine 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 product
A user product runs 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 product
A kernel product runs 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 device
A foreign device is a peripheral device installed during the initial system installation and bootstrap. Before a system manager can make use of the foreign device, the associated device driver must be configured into the kernel. The problem is that prior to the installation of the operating system, there is no kernel and there are no device drivers available to handle potential kernel and user requests of these foreign devices.
To solve this problem, a kit for a foreign device contains a kernel product -- the device driver for the foreign device -- and other files needed for configuring the driver into a kernel at system installation time.
The following are examples of hardware needed during the initial installation and bootstrap of the operating system:

1.2 Kit Formats

Prior to being copied onto the distribution media (diskette, CD-ROM, or tape), the product files are gathered into subsets. A subset groups together related files and specifies whether the group is required or optional for the installation procedure. You can 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 any disk media (CD-ROM, hard disk, or diskette) as a UNIX file system. Subsets distributed in DCD format cannot be compressed. The gendisk utility can create kits in DCD format.

Kits for user and kernel products should be produced in tar format; foreign device kits must be produced in DCD format.

1.3 Kit-Building Process

Figure 1-1 illustrates the process of creating and packaging a kit. 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.

Figure 1-1: Steps in the Kit-Building Process

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

Creating the kit directory structure that contains the source files
On the development system, you create the following directory structure for the kit you want to build:
This directory structure is the same for user products, kernel products, and foreign device kits. 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.

Creating subset control programs
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 device kits. Most layered products supply a subset control program, though the actions the programs perform differ for each product type. For example, the subset control program for a kernel product may call the kreg utility, while the subset control program for a user product would not.

Building subsets and control files
Before transferring your kit onto distribution media, 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 the master inventory file and key file. The newinv utility can help you maintain the master inventory.

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 tar format. You do this by selecting the appropriate packaging utilities, such as gendisk or gentapes. If you are creating a kit for a foreign device, you must also modify the kit and add files for the osfboot utility's bootstrap link support.

Testing the installation of the kit
After you have successfully created the kit, you should test the installation. For user products and kernel products, you install the kit by running the setld utility. For foreign devices, you use the osfboot utility's bootstrap link technology to install the kit and bootstrap a custom kernel. You may also want to install the kit on a RIS server so that RIS clients can install it across a network.

1.4 Sample Products

This book uses the following fictitious products to demonstrate how to build kits for each product type that Digital UNIX supports:

Orpheus Document Builder (ODB)
This application is one of a set of applications that the fictitious company, Orpheus Authoring Tools, Inc., produces. This example shows how to build a kit for a user product.

The /dev/none device driver
Writing Device Drivers: Tutorial introduces this peripheral device driver, which the fictitious company, EasyDriver, Inc., produces. This example shows how to build a kit for a kernel product.

The /dev/edgd device driver
This graphics device driver, which EasyDriver, Inc. also produces, shows how to build a kit for a foreign device.