4 Dynamic Device Recognition (DDR)

Most device management is automatic. A device added to a system is recognized, mapped, and added to the device databases as described in Chapter 3. However, you might sometimes need to add devices that the system cannot detect and add to the system automatically. These devices might be old, or new prototypes, or they might not adhere closely to supported standards such as SCSI. In these cases, you must manually configure the device and its drivers in the kernel, by using the ddr_config command described in this chapter.

This chapter discusses the following topics:

An overview of the kernel reconfiguration process (Section 4.1)

Using the dynamic method to reconfigure the kernel (Section 4.2)

Manually changing the DDR database (Section 4.3)

Converting customized Common Access Method (CAM) Data (Section 4.4)

How to create pseudoterminals (ptys), which are terminal pseudodevices that enable remote logins (Section 4.5)

4.1 Understanding Kernel Reconfiguration

You use two processes to reconfigure and rebuild a kernel:

The dynamic method uses the ddr command to rebuild the kernel and implement the disk configuration changes without shutting down the operating system.

The static method requires that you use the MAKEDEV and config commands. You must also shut down the system and restart it to rebuild the kernel and implement the changes.
Use the MAKEDEV command or the mknod command to create device special files instead of using the dsfmgr command. The kmknod command creates device special files for third-party kernel layered products. See MAKEDEV(8), mknod(8), and kmknod(8) for more information.
For loadable drivers, the sysconfig command creates the device special files by using the information specified in the driver's stanza entry in the /etc/sysconfigtab database file.

4.2 Using the Dynamic Method

The following sections explain how to use the ddr_config command to manage the Dynamic Device Recognition (DDR) database for your system. These sections introduce DDR, then describe how you use the ddr_config command to:

Add SCSI devices to the DDR database

Convert a customized cam_data.c file

4.2.1 Understanding Dynamic Device Recognition

DDR is a framework for describing the operating parameters and characteristics of SCSI devices to the SCSI CAM I/O subsystem. You can use DDR to add new and changed SCSI devices to your system without rebooting the operating system. You do not disrupt user services and processes, as happens with static methods of device recognition.

DDR is preferred over the static method for recognizing SCSI devices. The current, static method is to edit the /sys/data/cam_data.c data file and include custom SCSI device information, reconfigure the kernel, and shut down and reboot the operating system.

Note

Support for the static method of recognizing SCSI devices will be retired in a future release.

You can use both methods on the same system, with the restriction that the devices described by each method are exclusive to that method (nothing is doubly-defined).

The information DDR provides about SCSI devices is needed by SCSI drivers. You can supply this information by using DDR when you add new SCSI devices to the system, or you can use the /sys/data/cam_data.c data file and static configuration methods. The information provided by DDR and the cam_data.c file have the same objectives. When compared to the static method of providing SCSI device information, DDR minimizes the amount of information that is supplied by the device driver or subsystem to the operating system and maximizes the amount of information that is supplied by the device itself or by defaults specified in the DDR databases.

4.2.1.1 Conforming to Standards

Devices you add to the system should minimally conform to the SCSI-2 standard, as specified in SCSI-2, Small Computer System Interface-2 (X3.131-1994). If your devices do not comply with the standard, or if they require exceptions from the standard, you store information about these differences in the DDR database. If the devices comply with the SCSI-2 standard, you do not need to modify the database. The system will automatically recognize such devices and you can configure them by using the hwmgr command.

4.2.1.2 Understanding DDR Messages

The following list indicates the most common DDR message categories and the action, if any, that you should take:

Console messages are displayed during the boot sequence. Frequently, these messages indicate that the kernel cannot read the DDR database. This error occurs when the system's firmware is not at the proper revision level. Upgrade to the correct revision level of the firmware.

Console messages warn about corrupted entries in the database. Recompile and regenerate the database.

Runtime messages generally indicate syntax errors that are produced by the ddr_config compiler. The compiler runs when you use the -c option to the ddr_config command and does not produce an output database until all syntax errors are corrected.

Use the -h option to the ddr_config command to display help on command options.

4.2.2 Sample Database Entries

This section provides two examples of typical entries in the /etc/ddr.dbase file that support third-party products. This information will be supplied to you by the vendor of the supported device. Consult the vendors documentation for important information about setting the correct parameters for your installed version of HP Tru64 UNIX.

Caution

Do not use the sample entries included in this section. Contact the vendor of a device to obtain the latest configuration settings. HP does not provide configuration information for third-party devices other than for those listed in the system default /etc/ddr.dbase file.

4.2.2.1 Sample DDR Entry for a StorageTek 9840

The following sample DDR entry supports the StorageTek 9840 magnetic tape device. For information about the parameters, mode select, density, and attribute fields, see ddr.dbase(4). The hardware documentation supplied with the device must provide documentation about the attribute settings.

# Please note that this entry is not supported by HP
# It is supplied by StorageTek as a means of enabling
# their tape drive to work in HP Tru64 UNIX.
# If you experience problems when using this drive
# contact StorageTek Technical Support.
 
SCSIDEVICE
  #
  # STK 9840
  #
  Type = tape
  Name = "STK" "9840"
  #
 PARAMETERS:
  TypeSubClass 		= 3480
  MaxTransferSize 	= 0x40000     #256k
  SyncTransfers 	= enabled
  WideTransfers 	= enabled
  Disconnects 		= enabled
  CmdReordering 	= disabled
  TaggedQueuing 	= disabled
  TagQueueDepth 	= 0
  WCE_Capable 		= false
  PwrMgmt_Capable 	= false
  LongTimeoutRetry 	= disabled
  ReadyTimeSeconds 	= 240
  DisperseQueue 	= false
  CMD_PreventAllow	= supported
  CMD_ExtReserveRelease	= supported
 
 DENSITY:
	#
	# /dev/tape/tapeX_d0, _d4
	#
	DensityNumber = 0,4
	DensityCode = density_code_42
	CompressionCode = 0
	Buffered = 0x1
	#
 DENSITY:
	#
	# /dev/tape/tapeX_d1, _d5
	#
	DensityNumber = 1,5
	DensityCode = density_code_42
	CompressionCode = 1
	Buffered = 0x1
	#
	#
	# /dev/tape/tapeX_d2, _d6
	#
 DENSITY:
	DensityNumber = 2,6
	DensityCode = density_code_43
	CompressionCode = 0
	Buffered = 0x1
	#
	#
	# /dev/tape/tapeX_d3, _d7
	#
 DENSITY:
	DensityNumber = 3,7
	DensityCode = density_code_43
	CompressionCode = 1
	Buffered = 0x1
 
 
         Buffered = 0x1
 
     DENSITY:
         #
         DensityNumber = 1
         DensityCode = default
         CompressionCode = 0x1
         Buffered = 0x1

4.2.2.2 Sample DDR Entries for EMC Symmetrix

The following sample DDR entry supports the EMC Symmetrix disk storage array and Fibre Channel devices . For a description of the parameter, mode select, density, and attribute fields, see ddr.dbase(4).

The hardware documentation supplied with any third-party device must provide documentation about the attribute settings. In this example, the ATTRIBUTE settings include comments defining potential settings for the value of the ubyte[0] attribute. Consult the device's hardware documentation or contact the vendor for information about the settings.

SCSIDEVICE 
# 
# SAMPLE Entry for Symmetrix SCSI devices (DO NOT USE, CONSULT EMC) 
# 
Type = disk 
Name = "EMC" "SYMMETRIX"
PARAMETERS:
TypeSubClass = hard_disk, raid
BlockSize = 512
BadBlockRecovery = disabled
DynamicGeometry = true
LongTimeoutRetry = enabled
DisperseQueue = false
TagQueueDepth = 20
ReadyTimeSeconds = 45
InquiryLength = 160
RequestSenseLength = 160
PwrMgmt_Capable = false
ATTRIBUTE:
# ubyte[0] = 8 Disable AWRE/ARRE only, PR enabled
# ubyte[0] = 25 Disable PR & AWRE/ARRE, Enable I/O Barrier Patch resets
AttributeName = "DSBLflags"
Length = 4 
ubyte[0] = 8 
 
SCSIDEVICE 
# 
# Entry for Symmetrix Fibre Channel devices 
# 
Type = disk 
Stype = 2 
Name = "EMC" "SYMMETRIX"
PARAMETERS:
TypeSubClass = hard_disk, raid
BlockSize = 512
BadBlockRecovery = disabled
DynamicGeometry = true
LongTimeoutRetry = enabled
DisperseQueue = false
TagQueueDepth = 20
ReadyTimeSeconds = 45
InquiryLength = 160
RequestSenseLength = 160
PwrMgmt_Capable = false
ATTRIBUTE:
AttributeName = "DSBLflags"
Length = 4
ubyte[0] = 8

4.3 Manually Changing the DDR Database

When you make a change to the operating parameters or characteristics of a SCSI device, you must describe the changes in the /etc/ddr.dbase file. You must compile the changes by using the ddr_config -c command.

Two common reasons for changes are:

Your device deviates from the SCSI standard or reports something different from the SCSI standard.

You want to optimize device defaults, most commonly the TagQueueDepth parameter, which specifies the maximum number of active tagged requests the device supports.

You use the ddr_config -c command to compile the /etc/ddr.dbase file and produce a binary database file, /etc/ddr.db. When the kernel is notified that the file's state has changed, it loads the new /etc/ddr.dbase file. In this way, the SCSI CAM I/O subsystem is dynamically updated with the changes that you made in the /etc/ddr.dbase file and the contents of the on-disk database are synchronized with the contents of the in-memory database.

Use the following procedure to compile the /etc/ddr.dbase database:

Log in as root or become the superuser.

Enter the ddr_config -c command, for example:
```
# /sbin/ddr_config -c 
```

There is no message confirming successful completion. When the prompt is displayed, the compilation is complete. Any syntax errors are displayed as standard output and no output file is compiled.

4.4 Converting Customized cam_data.c Information

You use the following procedure to transfer customized information about your SCSI devices from the /sys/data/cam_data.c file to the /etc/ddr.dbase text database. In this example, MACHINE is the name of your machine's system configuration file.

Log in as root or become the superuser.

To produce a summary of the additions and modifications that you should make to your /etc/ddr.dbase file, enter the ddr_config -x command. For example:
```
# /sbin/ddr_config -x MACHINE > output.file
```
This command uses as input the system configuration file. (You specify the configuration file when you build your running kernel.) The procedure runs in multiuser mode and requires no input after it starts. Redirect output to a file to save the summary information. Compile errors are reported to standard error and the command terminates when the error is reported. Warnings are reported to standard error and do not terminate the command.

Edit the characteristics that are listed on the output file into the /etc/ddr.dbase file, following the syntax requirements of that file. Instructions for editing the /etc/ddr.dbase database are found in ddr.dbase(4).

Enter the ddr_config -c command to compile the changes.

See Section 4.3 for more information.

You can add pseudodevices, disks, and tapes statically (without using DDR) by using the methods described in the following sections.

4.5 Adding Pseudoterminals and Devices Without Using DDR

System V Release 4 (SVR4) pseudoterminals (ptys) are implemented by default and are defined as follows:

/dev/pts/N

The variable N is a number from 0-9999.

This implementation allows for more scalability than the BSD ptys (tty[a-zA-Z][0-9a-zA-Z]). The base system commands and utilities support both SVR4 and BSD ptys. To revert back to the original default behavior, create the BSD ptys by using the MAKEDEV command. See also SYSV_PTY(8), pty(7), and MAKEDEV(8).

4.5.1 Adding Pseudoterminals

Pseudoterminals enable users to use the network to access a system. A pseudoterminal is a pair of character devices that emulate a hardware terminal connection to the system. Instead of hardware, however, there is a master device and a slave device. Pseudoterminals, unlike terminals, have no corresponding physical terminal port on the system. Remote login sessions, window-based software, and shells use pseudoterminals for access to a system. By default, SVR4 device special files such as /dev/pts/n are created. You must use /dev/MAKEDEV to create BSD pseudoterminals such as /dev/ttyp/n. Two implementations of pseudoterminals are offered: BSD STREAMS and BSD clist.

For some installations, the default number of pty devices is adequate. However, as your user community grows, and each user wants to run multiple sessions of one or more timesharing machines in your environment, the machines might run out of available pty lines. The following command enables you to review the current value:

# sysconfig -q pts
pts:
nptys = 255

You can dynamically change the value with the sysconfig command, although this change is not preserved across reboots:

# sysconfig -r pts nptys=400

To modify the value and preserve it across reboots, use the following procedure:

Log in as superuser (root).

Add or edit the pseudodevice entry in the system configuration file /etc/sysconfigtab. By default, the kernel supports 255 pseudoterminals. If you add more pseudoterminals to your system, you must edit the system configuration file entry and increment the number 255 by the number of pseudoterminals you want to add. The following example shows how to add 400 pseudoterminals:
```
pts:
nptys=400
```
The pseudodevice entry for clist-based pseudoterminals is as follows:
```
pseudo-device pty 655
```
For more information on the configuration file and its pseudodevice keywords, refer to the configuration information in the System Administration manual.

For clist-based pseudoterminals, you also need to rebuild and boot the new kernel. Use the information on rebuilding and booting the new kernel in the System Administration manual.
When the system is first installed, the configuration file contains a pseudodevice entry with the default number of 255 pseudoterminals. If for some reason the number is deleted and not replaced with another number, the system defaults to supporting the minimum value of 80 pseudoterminals. The maximum value is 131072.

If you want to create BSD terminals, use the /dev/MAKEDEV command as follows:

Log in as root and change to the /dev directory.

Create the device special files by using the MAKEDEV command, as follows:
```
./MAKEDEV pty_#
```
The number sign ( # ) represents the set of pseudoterminals (0 to 101) you want to create. The first 51 sets (0 to 50) create 16 pseudoterminals for each set. The last 51 sets (51 to 101) create 46 pseudoterminals for each set. See MAKEDEV(8) for instructions on making a large number of pseudoterminals. (See the Tru64 UNIX QuickSpecs for the maximum number of supported pseudoterminals.)

Note

By default, the installation software creates device special files for the first two sets of pseudoterminals, pty0 and pty1. The pty0 pseudoterminals have corresponding device special files named /dev/ttyp0 through /dev/ttypf. The pty1 pseudoterminals have corresponding device special files named /dev/ttyq0 through /dev/ttyqf.
If you add pseudoterminals to your system, the pty# variable must be higher than pty1 because the installation software sets pty0 and pty1. For example, to create device special files for a third set of pseudoterminals, enter:
```
# ./MAKEDEV pty2
```
The MAKEDEV command lists the device special files it has created. For example:
```
MAKEDEV: special file(s) for pty2:
ptyr0 ttyr0 ptyr1 ttyr1 ptyr2 ttyr2 ptyr3 ttyr3 ptyr4 ttyr4
ptyr5 ttyr5 ptyr6 ttyr6 ptyr7 ttyr7 ptyr8 ttyr8 ptyr9 ttyr9
ptyra ttyra ptyrb ttyrb ptyrc ttyrc ptyrd ttyrd ptyre ttyre
ptyrf ttyrf
```

To remove BSD ptys, use the /dev/SYSV_PTY command.

If you want to allow root logins on all pseudoterminals, make sure an entry for ptys is present in the /etc/securettys file. If you do not want to allow root logins on pseudoterminals, delete the entry for ptys from the /etc/securettys file. For example, to add the entries for the new tty lines and to allow root login on all pseudoterminals, enter the following lines in the /etc/securettys file:
```
/dev/tty08     # direct tty
/dev/tty09     # direct tty
/dev/tty10     # direct tty
/dev/tty11     # direct tty
ptys
```
See securettys(4) for more information.

4.5.2 Adding Other Devices

When you add new SCSI devices to your system, the system automatically detects and configures them. It runs the appropriate hwmgr and dsfmgr commands to register the devices, assign identifiers, and create device special files. However, you might need to manually create device names for other devices by using the MAKEDEV command. You might also need to recreate device special files that you incorrectly deleted from the system.

For new devices, you must physically connect the devices and then make the devices known to the system. There are two methods, one for static drivers and another for loadable drivers. Before adding a device, read the owner's manual that came with your system processor and any documentation that came with the device itself. You might also require a disk containing the driver software.

Chapter 8 provides an outline example of adding a PCMCIA modem to a system, and shows you how to create the device special files.

You do not need to use the MAKEDEV command if you want only to create legacy rz or tz device special files in /dev such as /dev/rz5. The dsfmgr command provides a method of creating these device names. To add a device for a loadable driver, see the device driver documentation.

To add a device for a static driver, see Section 4.5.1.

Next, make the device special files for the device, by following these steps:

Change to the /dev directory.

Create the device special files by using the MAKEDEV command as follows:
```
# ./MAKEDEV deviceN
```
The device variable is the device mnemonic for the drive you are adding. The variable ( N ) is the number of the device. For example, to create the device special files for two PCMCIA modem cards, use the following command:
```
# ./MAKEDEV ace2 ace3
```
```
MAKEDEV: special file(s) for ace2:
tty02
MAKEDEV: special file(s) for ace3:
tty03
```
The generated special files should look like this:
```
crw-rw-rw-   1 root     system    35,  2 Oct 27 14:02 tty02
crw-rw-rw-   1 root     system    35,  3 Oct 27 14:02 tty03
```

Stop system activity by using the shutdown command and then turn off the processor. See the System Administration manual and shutdown(8) for more information.

Power up the machine. To ensure that all the devices are seen by the system, power up the peripherals before powering up the system box.

Boot the system with the new kernel. See the System Administration manual for information on booting your processor.