Object Data Manager
It is necessary to know something of the Object Data Manager (ODM) in order to understand the way in which AIX handles devices. The ODM manages object-oriented databases of system information. Among the databases it manages is that of device configuration. This database is made up of two object classes: the predefined object class and the customized object class. The predefined object class contains configuration information for all possible devices supported by AIX, and the customized object class contains information for devices actually on the system.Object Classes
An object class is a collection of objects with the same definition. Object class definitions resemble C language structures and are found in the /etc/objrepos (short for object repository) directory or in the directory specified by the ODMDIR variable. For example, the object definition for customized devices attached to the system is found in /etc/objrepos/CudDv and can be obtained by typing the odmshow command.# odmshow CuDv
class CuDv {
char name[16];
short status;
short chgstatus;
char ddins[16];
char location[16];
char parent[16];
char connwhere[16];
link PdDv PdDv uniquetype PdDvLn[48];
};
Each of the items in the CuDv object class definition is a descriptor. When an object is added to the CuDv object class, values are associated with each of the descriptors. For example, a SCSI hard disk with a location code of 00-00-0S-00 would have this code stored in the location descriptor. Objects
An object is an item that belongs to an object class. Each object has a set of configuration parameters corresponding to the descriptors in the object class definition. For example, to see the objects and their associated values that make up the CuDv object class, type:# odmget CuDv Among the stanzas in the output, you would likely see the following:
CuDv:
name = "hdisk0"
status = "1"
chgstatus = "2"
ddins = "scdisk"
location = "00-00-0S-00"
parent = "scsi0"
connwhere = "00"
PdDvLn = "disk/scsi/1000mb"
Each of the above lines corresponds to the CuDv object class definition. The last line is important in that it illustrates the hierarchical classification of devices. As stated earlier, the ODM database consists of more than device data, but within the realm of devices there is similar "class" terminology, which can be confusing at times. In the last line above, for example, disk is the device class, scsi is the device subclass, and 1000mb is the device type. Device Classes
A device class describes the basic function of the device. For example, there is a device class called adapter, a fairly generic description. A device subclass is a more specific description. sio (standard input/output) and mca (microchannel), for example, are subclasses of the adapter device class. Finally, a device type is the most specific description of the device: keyboard, tablet, mouse, and hscsi are types of the of the sio device subclass, which in turn is a member of the adapter device class.Although there are many ways to get this information, the following command provides a sorted list of currently defined devices on the system while at the same time illustrating further the concept of device classes:
# lsdev -C -F "class subclass type description" | sort adapter mca ppr POWER Gt3i Graphics Adapter adapter mca sio_1 Standard I/O Planar adapter sio fda Standard I/O Diskette Adapter adapter sio hscsi Standard SCSI I/O Controller adapter sio ient_1 Standard Ethernet Adapter adapter sio keyboard Keyboard Adapter adapter sio mouse Mouse Adapter adapter sio ppa Standard I/O Parallel Port Adapt adapter sio s1a_1 Standard I/O Serial Port 1 adapter sio s2a_1 Standard I/O Serial Port 2 adapter sio tablet Tablet Adapter bus sys mca Microchannel Bus disk scsi 1000mb 1.0 GB SCSI Disk Drive diskette siofd fd Diskette Drive fpa sys fpa1 Floating Point Processor hft node hft High Function Terminal Subsystem if EN en Standard Ethernet Network Inter if EN ie3 IEEE 802.3 Ethernet Network Inter if LO lo Loopback Network Interface ioplanar sys ioplanar_1 I/O Planar keyboard sio.kb kb101 United States keyboard logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume lvsubclass lvtype Logical volume logical_volume vgsubclass vgtype Volume group lvm lvm lvdd N/A memory sys memory 64 MB Memory Card mouse sio.ms mse_3b 3 button mouse planar sys sysplanar1 CPU Planar pty pty pty Asynchronous Pseudo-Terminal sys node aio Asynchronous I/O sys node sys System Object sysunit sys sysunit System Unit tape scsi 8mm5gb 5.0 GB 8mm Tape Drive tcpip TCPIP inet Internet Network ExtensionAs you can probably deduce from the command, the four columns above represent the class, subclass, type, and description of the currently defined objects on the system. Note that although the ppr (POWER Gt3i Graphics Adapter) and fda (Standard I/O Diskette Adapter) both belong to the same adapter device class, they belong to different subclasses: mca and sio, respectively.
Adding Supported Devices
Adding and removing devices requires manipulating the device configuration database via the ODM, a daunting task. If you use AIX device management commands like mkdev, rmdev, lsdev, lsattr, and chdev you need to be familiar with these class concepts and the ODM. However, two tools can greatly simplify the task: the cfgmgr command and SMIT.cfgmgr
The cfgmgr command, also known as the Configuration Manager, automatically configures devices on the system. It is run twice at system boot and can be run at the command line as well. When invoked, cfgmgr reads rules from the Config_Rules object class. These rules are commands that configure devices and make them available for use by creating device files and installing drivers. To see what these rules are, use the odmget Config_Rules command.Thus one way of adding, say, an 8mm, 5GB SCSI tape drive is to:
- Power down the system
- Connect the drive
- Power-on the drive
- Boot the system
# lsdev -C -c tapermt0 Available 00-00-0S-60 5.0 GB 8mm Tape Drive The term "Available" refers to the tape drive's state. A device has one of three states: undefined, defined, or available. If the tape drive is undefined, it has not been configured by cfgmgr. If it is defined, its configuration data is recorded in the customized database, but the device is not available for use. Once a defined device is bound to the kernel it is in the available state. cfgmgr will make sure your device is defined and then made available.
cfgmgr can also be run at the command line. If you add a device, such as the above tape drive, to a running system (even if it is a SCSI device), you have to run the cfgmgr command to make it available. Also, if you have an available but powered-down device when you reboot, the cfgmgr during bootup will set the device to a defined state. To make it available, power-on the device and rerun the cfgmgr command.
Adding a Device Using SMIT
You can attach a device to the system, power it on, and then use SMIT to configure it. To do so, just type smit device at the command line. You will see the following:Devices
Move cursor to desired item and press Enter. Configure Devices Added After IPL Printer/Plotter TTY Asynchronous Adapters PTY Console Fixed Disk CD ROM Drive Diskette Drive Tape Drive Communication High Function Terminal (HFT) SCSI Initiator Device SCSI Adapter Asynchronous I/O Multimedia List Devices
Just select the item you wish to add and press Enter. If you were to add the example 8mm tape drive to the system this way, you would select Tape Drive. The next screen would look like the following:
Tape Drive
Move cursor to desired item and press Enter. List All Defined Tape Drives List All Supported Tape Drives Add a Tape Drive Change / Show Characteristics of a Tape Drive Remove a Tape Drive Configure a Defined Tape Drive Generate Error Report Trace a Tape Drive
Select Add a Tape Drive. You will then be presented a list of supported tape drives, something similar to the following:
Tape Drive Type
Move cursor to desired item and press Enter.
1200mb-c scsi 1.2 GB 1/4-Inch Tape Drive
150mb scsi 150 MB 1/4-Inch Tape Drive
3490e scsi 3490E Autoloading Tape Drive
4mm2gb scsi 2.0 GB 4mm Tape Drive
4mm4gb scsi 4.0 GB 4mm Tape Drive
525mb scsi 525 MB 1/4-Inch Tape Drive
8mm scsi 2.3 GB 8mm Tape Drive
8mm5gb scsi 5.0 GB 8mm Tape Drive
9trk scsi 1/2-inch 9-Track Tape Drive
ost scsi Other SCSI Tape Drive
This list comes from the predefined device object class. If you are adding a non-IBM SCSI tape drive, choose ost scsi Other SCSI Tape Drive. In fact, any time you add an non-IBM SCSI device of any kind, there is always a generic SCSI option in SMIT for you to use. For our example, we will choose 8mm5gb scsi 5.0 GB 8mm Tape Drive. This will produce a dialog asking to choose a parent adapter:
Parent Adapter
Move cursor to desired item and press Enter.
scsi0 Available 00-00-0S Standard SCSI I/O Controller
Unless you have more than one adapter, you would choose scsi0 Available 00-00-0S Standard SCSI I/O Controller.
Finally, you will get the following screen:
Add a Tape Drive
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Tape Drive type 8mm5gb
Tape Drive interface scsi
Description 5.0 GB 8mm Tape Drive
Parent adapter scsi0
*CONNECTION address []
BLOCK size (0=variable length) [1024] #
Use DEVICE BUFFERS during writes yes +
Use EXTENDED file marks no +
DENSITY setting #1 140 +
DENSITY setting #2 20 +
Use data COMPRESSION yes +
Here the only required entry is the CONNECTION address, which is your SCSI address. Other parameters you can change as needed. Herein is the advantage of adding a device through SMIT: you can customize your configuration. Otherwise, using cfgmgr will add the device with default attributes. If the tape drive in this example is set to SCSI ID 6, you would enter 60 in the CONNECTION address field. [5] Pressing the Enter key at this point will execute the mkdev command and this will configure the drive to an available state.
Adding Unsupported Devices
The predefined object class supports all kinds of devices, most of which are IBM products. However, it does contain generic device objects. To see a list of those objects, enter the following command:# lsdev -P | grep -i other printer opp parallel Other parallel printer disk osdisk scsi Other SCSI Disk Drive tape ost scsi Other SCSI Tape Drive tmscsi tmscsi scsi Other SCSI Initiator Device printer osp rs232 Other serial printer printer osp rs422 Other serial printer cdrom oscd scsi Other SCSI CD-ROM DriveIf your device is not part of the predefined object class and closely resembles one of the above objects, then using one of them when adding a device through SMIT may very well work. Often cfgmgr will do just that when it encounters an unknown device. However, if this doesn't work you have no choice but to modify the predefined object database, write the necessary device methods, write a device driver (if necessary), and install the software to support the driver. Consult Device Driver Kernel Extension Overview in InfoExplorer for more information.
Removing Devices
When you physically remove a device from the system, cfgmgr resets the device state to defined the next time a reboot occurs in case you want to reattach it later. If you want to set the device state to defined without rebooting the system, use the rmdev command. The syntax of the rmdev is:rmdev -l Name Name is the logical name of the device. To find the logical names of the customized devices, use the lsdev -C command. The first column of this command's output is the logical names of the devices. Thus, to remove our example 8mm drive you type:
# rmdev -l rmt0 This keeps the rmt0 device configuration information in the customized database but sets its state to defined. To remove the drive entirely from the customized database, type:
# rmdev -d -l rmt0 The above can be done through SMIT. Just type smit device, select your device, and then choose the appropriate menu selection to remove it. You will be prompted as to whether or not you want to keep the device in the customized database.
5.3 HP-UX
HP-UX follows a more traditional method of adding a device: before a device can be used its device driver must be compiled into the kernel. The default kernel configuration of HP-UX will probably meet the needs of most systems. However, to keep the size of the kernel small, some drivers may not be present. If you need to add a device whose driver is not a part of the kernel, you will have to create a new one.Adding a Device without Modifying the Kernel
The basic steps of doing so are:- Add your device to the system. This usually requires shutting down the system, attaching the device, and rebooting; for SCSI devices it is required.
- Determine how the device is to be accessed: block or character (raw) mode. A device file must exist for each type of access to the device.
- Determine if the device file necessary to communicate with the device already exists on your HP-UX system.
- If the appropriate device file does not exist for the newly installed device, you must create one. If you are using SAM to add your device, SAM will create the device file. If you are not using SAM, use the mknod command to create the device file.
Device Files
Device files provide user-level access to the device drivers found in the kernel. These files are found in the /dev directory. Consider the following command and its output:# ls -l /dev/console /dev/*dsk crw--w--w- 1 root sys 0 0x000000 Apr 16 12:56 /dev/console /dev/dsk: total 0 brw-r--r-- 1 root sys 7 0x410200 Apr 16 09:08 c42d0s0 brw-r--r-- 1 root sys 7 0x201600 Jan 14 16:41 c201d6s0 /dev/rdsk: total 0 crw-r--r-- 1 root sys 47 0x410200 Apr 16 09:08 c42d0s0 crw-r--r-- 1 root sys 47 0x201600 Mar 18 15:30 c201d6s0The first character of each line identifies the type of device file. A b denotes a block device, and a c indicates a character device. A block device transfers data a block at a time by using the system buffers. A disk drive holding a mountable file system is an example of a block device. A character device reads or writes data one character at a time. Tape drives are usually character devices. Some devices are capable of I/O in both block and character mode. Such devices require two device files: one for block and one for character mode. A hard disk is an example of a device which uses both character and block device files. For purposes of mounting the disk as a file system, you will use the block device file. For purposes of accessing the disk for backups, the character device file is used.
The major and minor numbers appear immediately before the date. The major number identifies what kernel driver is being referred to by the device file. The value chosen for the major number is based on both the device driver and on the access method (block or character). For devices needing both a character and block device file, there are different character major numbers and block major numbers. You can use the lsdev command to list the device drivers and their major numbers in the system. For example:
# lsdev
Character Block Driver
0 -1 /dev/console
1 -1 HP98628, HP 98626, and HP98642
2 -1 /dev/tty
3 -1 /dev/mem, /dev/kmem, and /dev/null
16 -1 Master pty
17 -1 Slave pty
23 -1 raw 8042 HIL
24 -1 HIL
25 -1 HIL cooked keyboards
47 7 SCSI disk
52 -1 IEEE 802 device
121 -1 SCSI tape
55 10 Optical Autochanger
The first two columns document character and block major numbers respectively. A -1 in either column means that a major number does not exist for that type of driver. Note that in the example above the SCSI disk driver has both a character and a block major number. Thus a long listing of the device files for such a disk at SCSI address 6 would look like the following: # ls -l /dev/*dsk/c201d6s0 /dev/dsk: total 0 brw-r--r-- 1 root sys 7 0x201600 Jan 14 16:41 c201d6s0 /dev/rdsk: total 0 crw-r--r-- 1 root sys 47 0x201600 Mar 18 15:30 c201d6s0The directory containing the block device file, with a major number of 7, is /dev/dsk, and the directory with the character device file in it is /dev/rdsk. (The letter r is used here because character mode is often referred to as "raw" mode; block mode is sometimes called "cooked" mode.) You can also see device major numbers in the /etc/master file.
The minor number is an encryption of address and configuration information. It typically defines one or both of the following: 1) the device's physical address, and 2) operational information, such as tape density or rewind options in the case of tape drives. Note that the minor number and the device file name are similar. There is a reason for that, which brings us to the next topic.
Device File Naming Conventions
HP-UX follows a naming convention for device files which it employs on preloaded systems and when SAM is used to create device files. You can use whatever name you want when you create a device file, but if you follow the naming convention you will find it easier to locate and identify a particular device file. To make the names easier to remember you can create the device file using the naming convention and then link that name to one like /dev/tape1 or /dev/cd.The device file name for the most common devices begins with the letter c, which stands for the controller number. What follows the letter c is either the number 20, which indicates the core I/O module of the system bus, or 4, indicating the EISA bus adapter. Next is a number indicating function of the controller. The number 1 is for the SCSI function. Next is usually the letter d, which stands for the device number, or bus address. Often there follows additional numbers or letters that indicate additional information. The following are examples of disk device files. The letter s indicates the section number, which is always zero unless software disk striping is used.
/dev/[r]dsk/c201d6s0 | SCSI disk on the core I/O module at bus address 6 |
/dev/[r]dsk/41d3s0 | SCSI disk on the EISA slot at bus address 3 |
The following is an example of an optical autochanger device file:
/dev/[r]ac/c201d3_1a | SCSI optical autochanger at bus address 3, disk1, side a |
Tape drive device files have the following possible values in addition to the controller number and address number:
h | High density of 6250 bpi |
m | Medium density of 1600 bpi |
l | Low density of 800 bpi |
c | Indicates data compression (only for drives that support compression) |
n | Indicates no rewind upon close of device |
b | Indicates Berkeley-style tape behavior |
525|150|120 | Indicates the format of a quarter-inch tape drive |
Example tape drive device files:
/dev/rmt/c201d3h | SCSI tape drive at bus address 3, high density |
/dev/rmt/c201d3mn | SCSI tape drive at bus address 3, medium density, no rewind on close |
Creating Device Files
You can use SAM to create device files. SAM will create the files using the recommended naming convention, create both block and character versions where needed, and assign the appropriate major and minor numbers. In many cases using SAM to do these tasks is the best way to go, especially in the case of tape drives, since there are often as many as 16 different device files for each one you install. And since the minor numbers are hexadecimal values, using SAM can make things a lot easier.However, you can create device files manually by invoking the mknod command. The syntax of mknod is:
mknod name c|b major number minor number Name is the device name, preferably based on the naming convention. The c or b indicates that the file is either a character device file or a block device file, respectively. Major number is derived from either the lsdev command or the /etc/master file. That leaves us with an explanation of how to form the minor number.
The minor number format is 0xSFDDD where:
0x indicates hexadecimal notation (hex is required)
S is the system bus module number. Remember that 20 is for core I/O, and 4 is for EISA.
F is the function number. The function numbers are:
- 1 for SCSI
- 2 for LAN
- 3 for HIL
- 4 for serial port A
- 5 for serial port B
- 6 for parallel port
Driver-specific Designations
Peripheral type | Format of DDD | Syntax |
SCSI disk drive | TUV | T is the target number (bus address) |
Tape drive | TDO | T is the bus address D is density flag O is the operation bits |
Autochanger | TS | T is the bus address |
Parallel printer | T00 | T is the bus address |
For details on creating the appropriate minor numbers for all devices, see Chapter 14 of Installing Peripherals in the LaserRom documentation.
To help determine the appropriate minor number, you can use the ioscan -f command. ioscan searches the system provides, among other things, the hardware path number for each device it finds, and it is the hardware path number that forms the basis of the minor number. For example:
# ioscan -f Class H/W Path Driver H/W Status S/W Status ======================================================= scsi 2.0.1 c700 ok(0x7071) ok disk 2.0.1.1.0 scsi ok(0x5800202) ok disk 2.0.1.2.0 scsi ok(0x201) ok tape_drive 2.0.1.3.0 scsitape ok(0x1800202) ok disk 2.0.1.4.0 scsi ok(0x201) ok disk 2.0.1.6.0 scsi ok(0x101) ok lan 2.0.2 lan01 ok(0x7072) ok hil 2.0.3 hil ok(0x7073) ok serial 2.0.4 asio0 ok(0x7075) ok serial 2.0.5 asio0 ok(0x7075) ok parallel 2.0.6 parallel ok(0x7074) ok scsi 4.1.0 c700 ok(0x7680) ok disk 4.1.0.4.0 scsi ok(0x201) ok disk 4.1.0.5.0 scsi ok(0x201) ok disk 4.1.0.6.0 scsi ok(0x201) okFor the SCSI disk listed above whose hardware path number is 2.0.1.1.0, for example, the appropriate minor number would be 0x201100. This can be interpreted as follows:
0x | Hexadecimal notation |
20 | The core I/O card on system bus module 2 |
1 | SCSI function number |
100 | Bus address 1, unit 0, volume 0 |
Remember, if you have difficulty in coming up with the correct minor number, or any other part of the device file creation process, just use SAM to do it for you
Modifying the Kernel in Order to Add a Device
For most systems, the default kernel configuration is sufficient and you will not have to modify the kernel configuration in order to add a device. However, kernel drivers such as cs80 (Series 300/400/700) and hshpib are not included in the default configuration. These drivers are needed for the optional EISA HP-IB card and its peripherals (for example, to communicate with an HP-IB DDS-format drive). To configure them, you must rebuild the kernel.Using SAM to Rebuild the Kernel
Using SAM is the easiest way to rebuild the kernel. In the case of devices SAM will also make sure your device files are created. SAM will make changes to the /etc/conf/dfile file, the kernel configuration file, and will use it to build the new kernel. SAM will always show you a list of whatever you are configuring with values in one of two categories: current and pending. The pending values are those you have changed in /etc/conf/dfile and which will be the new kernel values when you have created a new kernel and rebooted the system. The current values are those in the current running kernel.When you have completed all the kernel changes you wish to make using SAM, you should choose the Create a New Kernel action. When the new kernel has been created, you will be given the choice of 1) moving the kernel into place and rebooting the system immediately, 2) moving the kernel into place but not rebooting the system, or 3) exit without moving the kernel into place.
Rebuilding the Kernel Manually
/etc/conf/dfile contains an entry for all peripheral devices, I/O cards, and major software subsystems such as LAN, RJE, and X25. To add a device, card, or subsystem to the kernel, you must add an entry for it in the dfile. To determine what entry to add to the dfile you should examine /etc/master. The /etc/master file is the device information table that contains the device name, handler name, element characteristics, functions for the device, and major device number. If what you are trying to add is not in the /etc/master file, then it is not supported by HP.Let's assume you want to add a SCSI floppy drive to your system. First you would check /etc/master to make sure it's supported and then add scsifloppy to the dfile. Assuming your working directory is /etc/conf, you would enter the following commands:
# config dfile # make -f config.mk # mv /hp-ux /SYSBCKUP # mv hp-ux # cd / # reboot
5.4 Summary
The handling of device differs greatly between AIX and HP-UX. AIX uses the Object Data Manager to handle devices, and HP-UX uses traditional AT&T-style device files and kernel drivers. The easiest way to add a device in AIX is to connect it to a powered-down system, turn it on, and boot the system. During the boot process the cfgmgr utility is run, which configures the device and adds it to the customized device configuration database. It also runs rules that create the appropriate device files. You can run cfgmgr at the command line or use SMIT to add a device. These two methods ensure that not only the appropriate device files are created, but that the ODM's customized device database is maintained. If you need to add a device not listed in the predefined device database, you can use generic entries that will work. This enables you to add devices without having to rebuild the kernel, something not done in AIX. Also, you normally do not create your device files with the mknod command, even though it exists in AIX.HP-UX requires that the appropriate driver be included in the kernel. If it is, you just attach the device to the system and create the appropriate device files with the mknod command, although many device files are already created for you in a preloaded system. If the driver is not in the kernel, you must 1) check that the appropriate driver is listed in the /etc/master file, 2) put an entry for that driver in the /etc/conf/dfile file, and 3) rebuild the kernel. After that you can create the appropriate device files. Both creating device files and rebuilding the kernel can be done through SAM, which is often the best way to go because figuring out what minor numbers to use can be a difficult task.
Regardless of how device files are created, both AIX and HP-UX use device files in the same way. These files are special files that provide user-level access to device drivers, so commands like tar can be used to read to and write from tape drives. For example, in AIX you can archive files in the /home directory to tape by typing:
# tar -cvf /dev/rmt0 /home Or in HP-UX:
# tar cvf /dev/rmt/c201d3mnb All you have to do is remember the locations of the device files on the respective systems. The following tables will help you do that for the most commonly used devices.
AIX File System Device Files
Block | Character |
/dev/hd1 | /dev/rhd1 |
/dev/hd2 | /dev/rhd2 |
/dev/hd3 | /dev/rhd3 |
/dev/hd* | /dev/hd* |
HP-UX File System Device Files
Block | Character |
/dev/dsk/c201d0s0 | /dev/rdsk/c201d0s0 |
/dev/dsk/c201d1s0 | /dev/rdsk/c201d1s0 |
/dev/dsk/c201d2s0 | /dev/rdsk/c201d2s0 |
/dev/dsk/c201d*s0 | /dev/rdsk/c201d*s0 |
AIX Tape Drive Device Files
File | Meaning |
/dev/rmt* | Rewind on close, no retension on open, high density |
/dev/rmt*.1 | No rewind on close, no retension on open, high density |
/dev/rmt*.2 | Rewind on close, retension on open, high density |
/dev/rmt*.3 | No rewind on close, retension on open, high density |
/dev/rmt*.4 | Rewind on close, no retension on open, low density |
/dev/rmt*.5 | No rewind on close, no retension on open, low density |
/dev/rmt*.6 | Rewind on close, retension on open, low density |
/dev/rmt*.7 | No rewind on close, retension on open, low density |
HP-UX Tape Drive Device Files
File | Meaning |
/dev/rmt/c201d*c | Rewind on close, compress data |
/dev/rmt/c201d*cb | Rewind on close, compress data, Berkeley style |
/dev/rmt/c201d*cn | No rewind on close, compress data |
/dev/rmt/c201d*cnb | No rewind on close, compress data, Berkeley style |
/dev/rmt/c201d*h | Rewind on close, high density |
/dev/rmt/c201d*hb | Rewind on close, high density, Berkeley style |
/dev/rmt/c201d*hn | No rewind on close, high density |
/dev/rmt/c201d*hnb | No rewind on close, high density, Berkeley style |
/dev/rmt/c201d*l | Rewind on close, low density |
/dev/rmt/c201d*lb | Rewind on close, low density, Berkeley style |
/dev/rmt/c201d*ln | No rewind on close, low density |
/dev/rmt/c201d*lnb | No rewind on close, low density, Berkeley style |
/dev/rmt/c201d*m | Rewind on close, medium density |
/dev/rmt/c201d*mb | Rewind on close, medium density, Berkeley style |
/dev/rmt/c201d*mn | No rewind on close, medium density |
/dev/rmt/c201d*mnb | No rewind on close, low density, Berkeley style |
Note: High density is 6250 bpi, medium is 1600 bpi, and low is 800 bpi. For AT&T-style devices the tape is positioned after the EOF following the data just read. For Berkeley-style devices, the tape is not repositioned in any way.
AIX Floppy Drive Device Files
Block | Character |
/dev/fd0 | /dev/rfd0 |
No comments:
Post a Comment