1scsi(4) File Formats scsi(4)
2
6 scsi - configuration files for SCSI target drivers
7
9 The architecture of the Solaris SCSI subsystem distinguishes two types
10 of device drivers: SCSI target drivers, and SCSI host adapter drivers.
11 Target drivers like sd(7D) and st(7D) manage the device on the other
12 end of the SCSI bus. Host adapter drivers manage the SCSI bus on behalf
13 of all the devices that share it.
14 Drivers for host adapters provide a common set of interfaces for target
17 drivers. These interfaces comprise the Sun Common SCSI Architecture (
18 SCSA) which are documented as part of the Solaris DDI/DKI. See
19 scsi_ifgetcap(9F), scsi_init_pkt(9F), and scsi_transport(9F) for fur‐
20 ther details of these, and associated routines.
21 Depending on the interconnect (transport), SCSI target devices are
24 either self-identifying or rely on driver.conf(4) entries to be recog‐
25 nized by the system. For self-identifying target devices the driver
26 binding is chosen based on the IEEE-1275 like 'compatible' forms of the
27 target devices. Currently the Fibre Channel interconnects, fcp(7D),
28 ifp(7D), scsi_vhci(7D), sf(7D), and the SATA framework drivers (see
29 sata(7D)) are self-identifying. You must specify other possible inter‐
30 connects target devices by using the target driver driver.conf(4) con‐
31 figuration files.
32 Self-Identifying
34 Host adapter drivers of class scsi-self-identifying that dynamically
35 create self-identifying target device children establish a compatible
36 property on each child. The compatible property is an ordered array of
37 strings, each string is a compatible form. High precedence forms are
38 defined first. For a particular device, the highest precedence form
39 that has an established driver alias selects the driver for the device.
40 Driver associations to compatible forms, called aliases, are adminis‐
41 tered by way of add_drv(1M), update_drv(1M), and rem_drv(1M) utilities.
42 The forms for self-identifying SCSI target devices are derived from the
45 SCSI target device's INQUIRY data. A diverse set of forms is defined,
46 allowing for flexibility in binding.
47 From the SCSI INQUIRY data, three types of information are extracted:
50 scsi_dtype, flag bits, and SCSI_ASCII vendor product revision.
51 The scsi_dtype is the first component of most forms. It is represented
54 as two hex digits. For nodes that represent embedded secondary func‐
55 tions, such as an embedded enclosure service or media changer, addi‐
56 tional forms are generated that contain the dtype of the secondary
57 function followed by the dtype of the device in which the secondary
58 function is embedded.
59 For forms that use flag bits, all applicable flags are concatenated (in
62 alphabetical order) into a single flags string. Removable media is rep‐
63 resented by a flag. For forms that use the SCSI_ASCII INQUIRY vendor,
64 product, and revision fields, a one-way conversion algorithm translates
65 SCSI_ASCII to a IEEE 1275 compatible string.
66 It is possible that a device might change the INQUIRY data it returns
69 over time as a result of a device initialization sequence or in
70 response to out-of-band management. A device node's compatible property
71 is based on the INQUIRY data when the device node was created.
72 The following forms, in high to low precedence order, are defined for
75 SCSI target device nodes.
76 scsiclass,DDEEFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR (1 *1&2)
78 scsiclass,DDEE.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR (2 *1)
79 scsiclass,DDFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR (3 *2)
80 scsiclass,DD.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR (4)
81 scsiclass,DDEEFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP (5 *1&2)
82 scsiclass,DDEE.vVVVVVVVV.pPPPPPPPPPPPPPPPP (6 *1)
83 scsiclass,DDFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP (7 *2)
84 scsiclass,DD.vVVVVVVVV.pPPPPPPPPPPPPPPPP (8)
85 scsiclass,DDEEFFF (9 *1&2)
86 scsiclass,DDEE (10 *1)
87 scsiclass,DDFFF (11 *2)
88 scsiclass,DD (12)
89 scsiclass (13)
90 *1 only produced on a secondary function node
91 *2 only produced on a node with flags
92 where:
96 v Is the letter v. Denotes the beginning of VVVVVVVV.
98 VVVVVVVV Translated scsi_vendor: SCSI standard INQUIRY data
101 "Vendor identification" SCSI_ASCII field (bytes
102 8-15).
103 p Is the letter p. Denotes the beginning of
106 PPPPPPPPPPPPPPPP.
107 PPPPPPPPPPPPPPPP Translated scsi_product: SCSI standard INQUIRY data
110 "Product identification" SCSI_ASCII field (bytes
111 16-31).
112 r Is the letter r. Denotes the beginning of RRRR.
115 RRRR Translated scsi_revision: SCSI standard INQUIRY
118 data "Product revision level" SCSI_ASCII field
119 (bytes 32-35).
120 DD Is a two digit ASCII hexadecimal number. The value
123 of the two digits is based one the SCSI "Peripheral
124 device type" command set associated with the node.
125 On a primary node this is the scsi_dtype of the
126 primary command set; on a secondary node this is
127 the scsi_dtype associated with the embedded func‐
128 tion command set.
129 EE Same encoding used for DD. This form is only gener‐
132 ated on secondary function nodes. The DD function
133 is embedded in an EE device.
134 FFF Concatenation, in alphabetical order, of the flag
137 characters below. The following flag characters are
138 defined:
139 R Removable media: Used when scsi_rmb is set
141 Forms using FFF are only be generated if there are
143 applicable flag characters.
144 Solaris might create additional compatible forms not described. These
148 forms are for Solaris internal use only. Any additional use of these
149 forms is discouraged. Future releases of Solaris might not produce
150 these forms.
151 driver.conf
153 Configuration files for SCSI target drivers should identify the host
154 adapter driver implicitly using the class keyword to remove any depen‐
155 dency on the particular host adapter involved.
156 All host adapter drivers of class scsi recognize the following proper‐
159 ties:
160 target Integer-valued SCSI target identifier that this driver
162 claims.
163 lun Integer-valued SCSI logical unit number ( LUN) that this
166 driver claims.
167 All SCSI target driver configuration file device definitions except
171 stub device definitions for discovery of devid must provide target and
172 lun properties. These properties are used to construct the address part
173 of the device name under /devices. The stub device definitions for dis‐
174 covery of devid must be able to specify or imply the host adapter driv‐
175 ers that might have children that bind to the target driver. So all
176 SCSI target driver configuration file stub device definitions must be
177 defined by property class or parent.
178 The SCSI target driver configuration files shipped with Solaris have
181 entries for LUN 0 only. For devices that support other LUNs, such as
182 some CD changers, the system administrator can edit the driver configu‐
183 ration file to add entries for other LUNs.
184
186 Example 1 An Example Configuration File for a SCSI Target Driver
187 The following is an example configuration file for a SCSI target driver
190 called toaster.conf.
191 #
194 # Copyright (c) 1992, by Sun Microsystems, Inc.
195 #
196 #ident "@(#)toaster.conf 1.2 92/05/12 SMI"
197 name="toaster" class="scsi" target=4 lun=0;
198 Add the following lines to sd.conf for a six- CD changer on target 3,
203 with LUNs 0 to 5.
204 name="sd" class="scsi" target=3 lun=1;
207 name="sd" class="scsi" target=3 lun=2;
208 name="sd" class="scsi" target=3 lun=3;
209 name="sd" class="scsi" target=3 lun=4;
210 name="sd" class="scsi" target=3 lun=5;
211 It is not necessary to add the line for LUN 0, as it already exists in
216 the file shipped with Solaris.
217 Example 2 A Stub Device Definition of sd.conf
220 The following line is a stub device definition which implies the host
223 adapter drivers of class scsi-self-identifying might have children that
224 bind to the sd(7D) driver:
225 name="sd" class="scsi-self-identifying";
228
232 See attributes(5) for descriptions of the following attributes:
233 ┌─────────────────────────────┬─────────────────────────────┐
238 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
239 ├─────────────────────────────┼─────────────────────────────┤
240 │Availability │SUNWckr │
241 ├─────────────────────────────┼─────────────────────────────┤
242 │Interface Stability │Committed │
243 └─────────────────────────────┴─────────────────────────────┘
244
246 add_drv(1M), rem_drv(1M), update_drv(1M), driver.conf(4),
247 attributes(5), fcp(7D), ifp(7D), sata(7D), scsi_vhci(7D), sd(7D),
248 sf(7D), st(7D), scsi_ifgetcap(9F), scsi_init_pkt(9F), scsi_trans‐
249 port(9F)
250 Writing Device Drivers
253 ANS X3T9.2/82-2 SMALL COMPUTER SYSTEM INTERFACE (SCSI-1)
256 ANS X3T9.2/375D Small Computer System Interface - 2 (SCSI-2)
259 ANS X3T10/994D SCSI-3 Architecture Model (SAM)
262 IEEE 1275 SCSI Target Device Binding
265
267 With driver.conf(4) configuration, you need to ensure that the target
268 and lun values claimed by your target driver do not conflict with
269 existing target drivers on the system. For example, if the target is a
270 direct access device, the standard sd.conf file usually makes sd claim
271 it before any other driver has a chance to probe it.
272SunOS 5.11 30 May 2008 scsi(4)