1    Introducing Product Kits

This guide is intended to provide product and kit developers with the proper method to create a product kit. The following topics are discussed in this chapter:

• An overview of product kits (Section 1.1)

• Defining the different product types and describing the sample product used in this guide (Section 1.2)

• Describing the available formats for layered product kits (Section 1.3)

• Illustrating the kit-building process (Section 1.4)

1.1    Overview

A product kit is the collection of files and directories that represent new or upgraded software to be installed onto a customer's system. The kit contains not only the actual files and directories that compose the product, but also contains the supporting files that are required to install the product on the system. The product kit is the standard mechanism by which most products are delivered and maintained on a customer's system. Kits for user and kernel products can be distributed on a CD-ROM, diskette, or tape for installation onto the customer's system. Hardware product kits can be delivered only on CD-ROM.

Note

A consolidated firmware CD-ROM lets you upgrade your processor firmware at the same time that you install the operating system. Appendix A describes how to create a consolidated firmware CD-ROM.

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 operating system?

• Is the kit being built for a hardware product?

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 operating system supports.

Once you determine the type of product kit that you are creating, you can use the specific chapters in this manual as shown in Figure 1-1:

Figure 1-1:  Using This Manual

This manual uses the fictitious Orpheus Document Builder (ODB) product to demonstrate how to build kits for each product type. OAT is the code assigned to Orpheus Authoring Tools, Inc., the fictitious company developing the ODB product, and 100 is the product version number. The same product is used for each type of product kit, but Chapter 4, Chapter 5, and Chapter 6 describe the files specific to user, kernel, and hardware product kits.

1.2    Product Types

The process described in this book lets you deliver layered products for a customer's system. A layered product is any software product that is not part of the base operating system. There are three kinds of layered products:

• User product

  A user product runs in user space. Commands and utilities are in this category, as are applications such as text editors and database systems. Users interact directly with user products, for example, through commands or window interfaces.

  A user product is a layered product that contains software run directly by users. Commands and utilities are in this category, as are applications such as text editors and database systems. Users interact directly with user products through such means as commands or graphical 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 and then calls the required driver interface.

• Hardware product

  A hardware product provides the kernel modules necessary for the operating system to support new or additional hardware. Before a system manager can use the hardware, the hardware product kit must be configured into the kernel, since there are no kernel modules available to handle potential kernel and user requests for the hardware. The hardware product kit contains a kernel product -- the device driver for the hardware -- and other files needed for configuring the driver into a kernel at system installation time. A hardware product kit can be installed either concurrent with or after the operating system installation.

1.3    Kit Formats

Before 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 they are required or optional for the product. You can copy the product files onto the distribution media in one of the following formats:

• Compressed tar format

  In compressed tar format, the product files belonging to the same subset are written to the distribution media as a single file. Kits for user and kernel products should be produced in compressed tar format. During installation, the setld utility uncompresses the files and moves them onto the customer's system, preserving the files' original directory structure. The gentapes and gendisk utilities can create kits in compressed tar format.

• Direct CD-ROM (DCD) format

  In direct CD-ROM (DCD) format, the files are written to any disk media (CD-ROM, hard disk, or diskette) as a UNIX file system (UFS). Subsets distributed in DCD format cannot be compressed. The gendisk utility can create kits in DCD format. Hardware product kits must be produced on CD-ROM in DCD format.

1.4    Kit-Building Process

Figure 1-2 illustrates the process of creating and packaging a kit. In the figure, boxes drawn with dashed lines 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 Figure 1-2, the commands enclosed in ovals perform the associated steps of the kit-building process.

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

The kit-building process consists of the following steps:

1. Create the kit directory structure that contains the source files.

   On the development system, create the following directory structure for the kit you want to build:

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

   • A data hierarchy, which contains files needed to build the kit

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

   Figure 1-3 illustrates these directory hierarchies.

   Figure 1-3:  Kit Directory Hierarchies

   

   This directory structure is the same for user products, kernel products, and hardware product kits. Only the contents of these directories differ among the product types. For example, a hardware product kit needs additional files that are unique to this specific kit type. Refer to Chapter 4, Chapter 5, and Chapter 6 for additional information about the requirements for each product kit type.

2. Create kit production files.

   This includes a master inventory file containing information about each file in the subset, a key file to define product attributes such as the product name, product version, and subset definitions, and additional files for kernel and hardware product kits.

3. Create subset control programs (if needed).

   The setld utility can call a subset control program (SCP) to perform installation steps specific to your kit. You supply an SCP for your kit only if the product requires special installation steps, such as those needed for kernel product kits and hardware product kits. The SCP is optional for user products. 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 to maintain the system file that registers kernel layered products, while the subset control program for a user product would not.

4. Build 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 and key files. Invoke the kits utility from the same directory where the master inventory file is located. Refer to Chapter 3 for information about the master inventory and key files.

5. Test subsets.

   You must test your subsets to ensure that they can be loaded onto a running system, that the product runs on the system, and that the subsets can be deleted. Subset testing includes loading all subsets onto a running system and deleting all subsets from a running system. If your kit includes optional subsets, you also should load the mandatory subsets onto a running system to determine if the product works as expected. If not, you may have to reclassify some optional subsets as mandatory.

6. Produce 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. To do this, use the gendisk or gentapes utility. If you are creating a kit for a hardware product, you also must modify the kit and add files to support your system's bootstrap link. Hardware product kits must use DCD format, and can be produced only with the gendisk utility.

7. Test product kit media.

   After you have successfully created the kit, you should test its installation from the new media. Chapter 4, Chapter 5, and Chapter 6 tell you how to test the installation of each of the product kit types.