4.1 Introduction 4-1 4.2 Device Drivers 4-1
4.2.1 Installing Device Drivers 4-2 4.2.2 InstallingPreconfigured Drivers 4-3
4.2.3 Installing Older Drivers and Drivers Unaccompanied by Configuration Shell Scripts 4-4
4.2.4 Troubleshooting 4-7
4.2.5 Creating Special Device Files 4-8
4.3 Allocating and Deallocating Kernel Resources 4-8
,4.3.1 Reconfiguring Because of Persistent Error Messages 4-9 4.3.2 Reconfiguringfor Performance 4-10
4.3.3 Increasing Limited Resources 4-11 4.3.4 Freeing Kernel Space for Drivers 4-13 4.4 Testing and Installing the New Kernel 4-14
4.4.1 Booting the New Kernel 4-14 4.4.2 Creating A New Ixenix 4-15 4.4.3 Removing the Link Kit 4-15
4.1 Introduction
This chapter explains how to add device drivers to the XENIX kernel, tailor various kernel resource allocations to a given application, and customize many details of the operating environment.
To change any component of the XENIX kernel it is necessary to use the Link Kit to relink the kernel. The Link Kit consists of a set of kernel com-ponents in the form of relocatable object modules plus various programs and shell scripts used to link the components together.
The most common use for the Link Kit is to add device drivers to the sys-tem. A device driver is the software interface between a peripheral device and the operating system. Each device that can be used with XENIX must have a device driver. New drivers are generally supplied when adding a peripheral device to the system; they must be configured into XENIX before the device will function.
The Link Kit is also necessary to create new device drivers, and is used in conjunction with other tools that are included with the XENIX Develop-ment System. The device driver material in this chapter is intended for those who want to install an existing device driver. Driver writers should read Chapter 8, "Writing Device Drivers", of the C User's Guide. Exam-ple device drivers are in Chapter 9, "SamExam-ple Device Drivers" of the C User's Guide.
Users of specialized applications will also find the Link Kit useful for mak-ing the operatmak-ing system conform more closely to the needs of the applica-tion. For example, users with large databases may find that they need to lock more files simultaneously than the current allocation of file locks will permit. Users who have no need for specialized XENIX features such as message handling may find that they can get a slight performance boost by deallocating those features and allocating additional disk buffers.
4.2 Device Drivers
A device driver is a set of routines that communicates with a hardware dev-ice, and provides a means by which XENIX can control the device in order to perform Input/Output (I/O) operations.
A device driver is usually supplied as a single software module. Installing this software into the kernel is as important as the actual hardware installa-tion. It must be completed before the device can be used. A driver is usu-ally accompanied by an auxiliary program or shell script that helps to form the links between driver and kernel.
4-1
XENIX Installation Guide
To install a new device driver:
Install the hardware device on the system according to the manufacturer's instructions.
Boot the system and enter system maintenance mode. All the operations described as part of the installation process are carried out in this mode
Make sure the Link Kit is installed. If it is not already installed, install it using the custom(C) command, described in the Reference Manual.
If this system's kernel has already been modified, copy the configuration files back from where they were previously stored.
For example, type:
# cd lusrlsys/conf
# cp .. lio/master . .fio/xenixconf . .fio/linkJenix . .fiol driver. 0 where driver. 0 is the name of the driver installed earlier, if any.
Note that the number sign (#) that precedes example commands is the super-user prompt. Do not type the number sign. In the example, this indicates that all link kit use should be carried out while logged in as the super-user, orin Single User Maintenance Mode.
4.2.1 Ins talling Device Drivers
The exact instructions for installing a new device driver are different for each type of device. This section contains example commands that may be slightly different than the actual commands. Read the specific installation instructions that are provided with the device driver software.
After the Link Kit is installed and the instructions read, the next step depends on how much of the work has already been done by the driver's vendors.
Many software vendors provide automatic driver installation utilities com-patible with the standard System V installation utilities. If so, insert the vendor's floppy in the floppy drive and enter:
# custom
Select the option to add a supported product, and follow the instructions that appear on the screen. custom should run any System V compatible, automatic installation software provided with the driver. This installs the device driver software and links a version of the kernel that contains the new device driver. After cus tom completes, the next step is usually to test
4-2
the newly created kernel. See the device driver documen tation for details.
If no mention is made of custom in the documentation for the individual driver, use the following procedure.
Move to the directory containing the link kit and copy the necessary files by entering:
# cd lusrlsys/conf
# cp master master.old
# cp xenixconf xenixconLold
Some older installation sets contain their own versions of master and xenixconf. These files record the system configuration. If the installation floppy contains its own master and xenixconf files, an out-of-date and possibly obsolete kernel will be generated.
Insert the floppy containing the driver into the floppy drive and enter the following to extract the con ten ts of the installation floppy:
# tar xvf Idev/install
Examine the names of the extracted files. If there are no files named mas-ter, xenixconf, c.o, or c.c on the driver installation floppy, the driver is preconfigured. Proceed to "Installing Preeonfigured Drivers" of this chapter. Otherwise, proceed to "Installing Older Drivers and Drivers Unaccompanied by Configuration Shell Scripts" to determine the com-mands necessary to configure the driver.
4.2.2 Ins taIling Pre configured Drivers
The driver installation floppy may come with a shell script that edits the link command line to include the new driver. If such a script is present, run it by entering:
# .Iscript
The documentation should indicate the actual name of script; it is unlikely to literally be script. Most scripts also create all necessary device nodes; if this is the case, proceed to "Booting the New Kernel."
If no such script is present, edit the file link-xenix to include the names of all object files provided. The object files are the files on the distribution media whose names end in
".0",
as in tape.o. Add the names of any new modules to the ld command line, just before the pairs of arguments of the4-3
XENIX Installation Guide
form "-1 libJxxx".
Enter
# .I1inkJenix
Linking will take approximately 10 minutes. Once a new XENIX kernel has been created, proceed to "Creating Special Device Files."
4.2.3 Installing Older Drivers and Drivers Unaccompanied by Configuration Shell Scripts
Any driver configuration shell script that neither installs a preconfigured driver nor calls configure dates from before the 2.2 release of XENIx.
Many older drivers will work fine with the XENIX 2.2 release, but their shell scripts are no longer usable. If this is the case, the script must be ignored and the procedure is the same as for a driver unaccompanied by a configuration shell script.
Note
SCO makes no warranty, expressed or implied, that any driver work-ing with any earlier release will remain compatible with a 2.2 or later kernel. The following procedure will allow an earlier driver to be configured. However, there are dozens of reasons why an earlier driver may no longer function, few of them directly determinable.
Out of date drivers may simply malfunction when attempting to access their peripherals, or they may cause a system crash or even more insidious malfunctions. For this reason, make backup copies of all important files before attempting to configure an older driver, and test drivers only in Sin-gle User Maintenance Mode.
1. Repeat the following procedure for each device driver. Enter:
# rm c.o c.*.o space.o space.*.o
Ignore any error messages of the form "c.o non-existent" or
"space.o non-existent."
2. If files named master and xenixconf were extracted when the tar command was entered, copy the old master and xenixconffiles back to their original names. This will overwrite the versions of master
4-4
and xenixconfthat came with the driver. For example, use the installation media whose names end in ".0". Enter:
# ./routines module1.o module2.0 ...
where modillel.o modllle2.o ... are the list of the driver modules provided. The list is most likely one module long, but if there's more than one, list them all.
This command can take as long as 5 minutes. Write down the names produced. Most of these names are either configurable driver rou-tines or driver priority levels. Some names may be spurious.
5. Driver priority levels have names consisting of the string spl fol-lowed by a number between 0 and 7. If there are any strings begin-ningwith spl present, write down the largest such number under the heading Interrupt Priority Level. Then cross all spl routines off the list.
6. Configurable driver routines all have a common prefix, such as sio.
Each prefix is followed by one of a small group of suffixes: open, close, read, write, ioctl, strategy, halt, poll, intr, init tab, Jty, or stream. If there are files that do not fit this pattern, cross them out.
For example. running routines on the sio. 0 driver reveals a long list of routines that begin with sio, and a single routine, ttinit. In this case you would cross out ttinit because it doesn't begin with sio.
There are a few other routines in the sio driver that would also be crossed out, such as siopinit, because of the extra "p." sio is an extreme case: most drivers will not have spurious routine names scattered throughout the relevant ones.
7. If any routine ends with strategy or tab, the peripheral is a block dev-ice. If any routine ends with read, write, or ioctl, the device is a char-acter device. A peripheral may be both a block and a character dev-ice. If none of these routines are present, consider the peripheral a character device.
8. If there is a routine containing the name intr, refer to the hardware manual to figure out which vector or vectors the device is capable of
4-5
XENIX Installation Guide
interrupting. To get a list of the vectors that are currently in use, enter:
# .Ivectorsinuse
A few drivers are written to allow vector sharing, but it is better to give each device a unique vector whenever possible. Associate the peripheral with an appropriate vector or vectors. Write down the numbers chosen for the "Vectors".
9. The configure command has the following syntax and must be entered on a single line:
4-6
# .Iconfigure -b -c -m MajocDcvice_Nllmber -v Vcctococ VectocList -a LisCOLDrivecRoutines -1 InterrupcPriority_Level
The options have the following definitions and restrictions:
- b Use if configuring a "block" device .
• c Use if configuring a "character" device .
• m Should be followed by the MajorJ)evice.-Number deter-mined earlier.
- a Should be followed by the list of driver routines deter-mined by running routines and crossing out the extraneous entries.
-v Use only if the device has an intr routine; should be fol-lowed by the list of vectors determined earlier.
-I Use only if spl routines appeared when routines was run earlier, followed by the InterruptYriority_Level.
For example, had it been necessary to configure the serial I/O driver, the following command would have been used:
# .Iconfigure -c -m 5 -v 3 4 27 28 -a sioopen sioclose sioread sioclock sioioctl siointr siopoll sioinit -1 7
The ramdisk driver is a simpler example; had it not been present, it would have been added with the command:
# .Iconfigure -b -m 31 -a ramopen ramclose ram strategy ramtab configure will produce new C.o and space. 0 files containing updated
configuration information.
Note
If when routines is run a long list appears containing a number of different prefixes, each with a healthy complement of configuration suffixes, this driver package contains not one driver but a driver suite made up of several drivers. Treat each prefix as an individual driver, and run configure once for each prefix.
10. After configure has been run once for each driver, edit the file linkJenix to include the names of all object files provided. The object files are the files on the distribution media whose names end in ".0", as in tape.o. Add the names of any new modules to the Id command line, just before the pairs of arguments of the form "-I libJXXX". Enter:
# .Ilink-xenix
Note that linking takes a while. Once a new XENIX kernel has been linked, proceed to "Creating Special Device Files."
4.2.4 Troubleshooting
If the followingld error message appears:
Group "DGROUP" larger than 64Kbytes
Reduce the size of some of the other kernel data structures to compensate for the extra room that the new driver is taking up. See "Allocating and Deallocating Kernel Resources" in this chapter for detailed instructions.
For hand -configured drivers: if the new kernel links without error, but on boot-up gets to the letter D and no farther, it is possible that an initroutine produced when routines was run was never meant to be given on the configure command line. After rebooting the old XENIX, enter the follow-ing commands:
# cd lusr! sysl conf
# .lconfigure -d XXinit -m MajocJ)evice~umber -b -c
# .llink-xenix
where Major_Device_Number is the value determined earlier, and XXinit is the actual name of the initialization routine. Run link-xenix again, copy the kernel produced to the root directory, reboot, and try again.
4-7
XENIX Installation Guide
4.2.5 Crea ting Special Device Files
In order for programs to gain access to the newly installed devices they must also exist as files within the filesystem. These files are called special files and are usually located in the Idev directory. Once again, the specific installation instructions supplied with the device will give the precise details of the name to be used for the special file and the other parameters associated with it. In order to create a special file, use the mknod com-mand. Supply the name of the special file, its type (which can be either "b"
for a block device or "c" for a character device) and the major and minor device numbers associated with the device. For example, change direc-tories to Idevand enter a command similar to one of these:
# I etc/mknod hcdO b 1 0
# I etc/mknod rhcdO c 1 0
# I etc/mknod hqp c 7 0
Note the convention for setting up disk device names. A digit may be appended to the mnemonic to indicate the drive number. The "raw" dev-ice, or character special device, name has an "r" prefix.
The major device number of the device can be found in the "master" file.
Find a line in this file for an appropriate device. For example, a hypotheti-cal tape driver might be hypotheti-called "tape" at the beginning of the line, and "td"
somewhat further down the same line. The name of the driver should also correspond to the name of the object module. For example, tape. 0 should be called "tape" inside the master file.
Next, find the columns at the top of the file marked "bmaj" and "cmaj".
Search down these two columns until a line appears that describes the driver. Write down the block major device number (bmaj), and the charac-ter major device number (cmaD. If either bmaj or cmaj is "0", do not create any block or character nodes, respectively. Otherwise, these entries are the major device numbers for the driver.
4.3 Alloca ting and Dealloca ting Kernel Res ources
Besides installing device drivers, the other compelling reason to reconfigure the kernel is to focus the allocation of the kernel resources to the needs of a given set of applications.
Some application users will be driven to reconfigure their kernel by per-sistent kernel error messages appearing on the system console, such as "no files7' or "Inode Table Overflow." Other users may reconfigure their ker-nel to strive for better performance during a specific application. Still oth-ers may wan t greater amounts of limited resources such as those used for character-set mapping, orneed more space in order to add device drivers.
4-8
In all four cases, the method is the same: install the Link Kit, run configure to set the allocation of the appropriate resources, relink the kernel by invoking the shell script linkJ:enix, copy the kernel to the root directory, reboot, and test the new kernel.
If the Link Kit is not already installed, install it using the custom(C) com-mand, described in the Reference Manual. After it is installed, enter:
# cd lusrlsys/conf
To move to the directory containing the link kit. To run configure enter:
# .I configure
When the menu appears, choose a category by typing the number preced-ing it. The resources in that category will be displayed, one by one, each with its current value. Enter a new value for the resource, or to retain the current value, simply press RETURN. After all the resources in the category have been displayed, configure will return to the category menu prompt. Choose another category to reconfigure or exit configure by entering 'q'. The nex1 four subsections describe scenarios for reconfiguring and the kernel resources.
4.3.1 Reconfiguring Because of Persistent Error Messages
The kernel should not be reconfigured because a kernel error message was received once, or even a couple of times, but when a single message per-sists. First try to increase a resource by a small amount, and if the problem persists, increase it by 50 or even 100 percent of its original value. If the problem is still not solved, more detailed research will be required to locate the exact program and sequence that causes the error.
System Messages Inode Table Overflow
no file
Increase NINODE in the Files, Inodes, and Filesystems category. NFILE and NINODE are usually set equal, but NINODE may be less in environments where many links are common.
Increase NFILE in the Files, Inodes, and Filesystems category.
NFILE and NINODE are usually set equal, but NINODE may be less in environments where many links are common.
panic: Timeout table overflow
Increase NCALLin the "Clock" category.
4-9
XENIX Installation Guide
out of text
Increase NT EXT in the "Processes, Memory Management &
Swapping" category.
4.3.2 Reconfiguring for Performance
The system is configured such that greatest quantities of kernel resources are assigned to the most common tasks such as reading and writing from the disk, but performance of the more specialized features (such as inter-process communication) has not been ignored. This balance can be shifted to conform to individual requirements.
For more common application mixes, the most effective means of increas-ing performance is to allocate additional disk buffers. More disk buffers means that less time needs to be spent accessing data on the disk, so
For more common application mixes, the most effective means of increas-ing performance is to allocate additional disk buffers. More disk buffers means that less time needs to be spent accessing data on the disk, so