unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

scsi(4)                          File Formats                          scsi(4)



NAME
       scsi - configuration files for SCSI target drivers

DESCRIPTION
       The  architecture of the Solaris SCSI subsystem distinguishes two types
       of device drivers: SCSI target drivers, and SCSI host adapter  drivers.
       Target  drivers  like  sd(7D) and st(7D) manage the device on the other
       end of the SCSI bus. Host adapter drivers manage the SCSI bus on behalf
       of all the devices that share it.

       Drivers for host adapters provide a common set of interfaces for target
       drivers. These interfaces comprise the Sun Common SCSI  Architecture  (
       SCSA)  which  are  documented  as  part  of  the  Solaris  DDI/DKI. See
       scsi_ifgetcap(9F), scsi_init_pkt(9F), and scsi_transport(9F)  for  fur-
       ther details of these, and associated routines.

       Depending  on  the  interconnect  (transport),  SCSI target devices are
       either self-identifying or rely on driver.conf(4) entries to be  recog-
       nized  by  the  system.  For self-identifying target devices the driver
       binding is chosen based on the IEEE-1275 like 'compatible' forms of the
       target   devices.  Currently  only  the  Fibre  Channel  interconnects,
       fcp(7D), ifp(7D), scsi_vhci(7D), sf(7D), are self-identifying. You must
       specify  other ipossible interconnects target devices by using the tar-
       get driver driver.conf(4) configuration files.

   Self-Identifying
       Host adapter drivers that dynamically  create  self-identifying  target
       device  children  establish  a "compatible" property on each child. The
       "compatible" property is an ordered array of strings, each string is  a
       compatible  "form". High precedence forms are defined first. For a par-
       ticular device, the highest precedence form  that  has  an  established
       driver  alias selects the driver for the device. Driver associations to
       compatible  forms,  called  aliases,  are  administered   by   way   of
       add_drv(1M), update_drv(1M), and rem_drv(1M) utilities.

       The forms for self-identifying SCSI target devices are derived from the
       SCSI target device's INQUIRY data. A diverse set of forms  is  defined,
       allowing for flexibility in binding.

       From  the  SCSI INQUIRY data, three types of information are extracted:
       scsi_dtype, flag bits, and SCSI_ASCII vendor product revision.

       The scsi_dtype is the first component of most forms. It is  represented
       as  two  hex  digits. For nodes that represent embedded secondary func-
       tions, such as an embedded enclosure service or  media  changer,  addi-
       tional  forms  are  generated  that  contain the dtype of the secondary
       function followed by the dtype of the device  in  which  the  secondary
       function is embedded.

       For forms that use flag bits, all applicable flags are concatenated (in
       alphabetical order) into a single flags string. Removable media is rep-
       resented  by  a flag. For forms that use the SCSI_ASCII INQUIRY vendor,
       product, and revision fields, a one-way conversion algorithm translates
       SCSI_ASCII to a IEEE 1275 compatible string.

       It  is  possible that a device might change the INQUIRY data it returns
       over time as a  result  of  a  device  initialization  sequence  or  in
       response  to out-of-band management. A device node's "compatible" prop-
       erty is based on the INQUIRY data when the device node was created.

       The following forms, in high to low precedence order, are  defined  for
       SCSI target device nodes.

       scsiclass,DDEEFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR (1  *1&2)
       scsiclass,DDEE.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR    (2  *1)
       scsiclass,DDFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR   (3  *2)
       scsiclass,DD.vVVVVVVVV.pPPPPPPPPPPPPPPPP.rRRRR      (4)
       scsiclass,DDEEFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP       (5  *1&2)
       scsiclass,DDEE.vVVVVVVVV.pPPPPPPPPPPPPPPPP          (6  *1)
       scsiclass,DDFFF.vVVVVVVVV.pPPPPPPPPPPPPPPPP         (7  *2)
       scsiclass,DD.vVVVVVVVV.pPPPPPPPPPPPPPPPP            (8)
       scsiclass,DDEEFFF                                   (9 *1&2)
       scsiclass,DDEE                                      (10 *1)
       scsiclass,DDFFF                                     (11 *2)
       scsiclass,DD                                        (12)
       scsiclass                                           (13)
          *1 only produced on a secondary function node
          *2 only produced on a node with flags


       where:

       v

           Is the letter v. Denotes the beginning of VVVVVVVV.



       VVVVVVVV

           Translated  scsi_vendor: SCSI standard INQUIRY data "Vendor identi-
           fication" SCSI_ASCII field (bytes 8-15).



       p

           Is the letter p. Denotes the beginning of PPPPPPPPPPPPPPPP.



       PPPPPPPPPPPPPPPP

           Translated scsi_product: SCSI standard INQUIRY data "Product  iden-
           tification" SCSI_ASCII field (bytes 16-31).



       r

           Is the letter r. Denotes the beginning of RRRR.



       RRRR

           Translated scsi_revision: SCSI standard INQUIRY data "Product revi-
           sion level" SCSI_ASCII field (bytes 32-35).



       DD

           Is a two digit ASCII hexadecimal number. The value of the two  dig-
           its  is  based  one  the  SCSI "Peripheral device type" command set
           associated with the node. On a primary node this is the  scsi_dtype
           of  the  primary  command  set;  on  a  secondary  node this is the
           scsi_dtype associated with the embedded  function command set.



       EE

           Same encoding used for DD. This form is only generated on secondary
           function nodes. The DD function is embedded in an EE device.



       FFF

           Concatenation, in alphabetical order, of the flag characters below.
           The following flag characters are defined:


           R                Removable media: Used when scsi_rmb is set



           Forms using FFF are only be generated if there are applicable  flag
           characters.



       Solaris  might  create additional compatible forms not described. These
       forms are for Solaris internal use only. Any additional  use  of  these
       forms  is  discouraged.  Future  releases  of Solaris might not produce
       these forms.

   driver.conf
       Configuration files for SCSI target drivers should  identify  the  host
       adapter  driver implicitly using the class keyword to remove any depen-
       dency on the particular host adapter involved.

       All host adapter drivers of class scsi recognize the following  proper-
       ties:

       target          Integer-valued  SCSI target identifier that this driver
                       claims.



       lun             Integer-valued SCSI logical unit  number  (  LUN)  that
                       this driver claims.



       All  SCSI target driver configuration file device definitions must pro-
       vide target and lun properties. These properties are used to  construct
       the address part of the device name under /devices.

       The  SCSI  target  driver configuration files shipped with Solaris have
       entries for LUN 0 only. For devices that support other  LUNs,  such  as
       some CD changers, the system administrator can edit the driver configu-
       ration file to add entries for other LUNs.

EXAMPLES
       Example 1: An Example Configuration File for a SCSI Target Driver

       The following is an example configuration file for a SCSI target driver
       called toaster.conf.

       #
       # Copyright (c) 1992, by Sun Microsystems, Inc.
       #
       #ident "@(#)toaster.conf  1.2     92/05/12 SMI"
       name="toaster" class="scsi" target=4 lun=0;

       Add the following lines to  sd.conf for a six- CD changer on  target 3,
       with  LUNs 0 to  5.

       name="sd" class="scsi" target=3 lun=1;
       name="sd" class="scsi" target=3 lun=2;
       name="sd" class="scsi" target=3 lun=3;
       name="sd" class="scsi" target=3 lun=4;
       name="sd" class="scsi" target=3 lun=5;

       It is not necessary to add the line for LUN 0, as it already exists  in
       the file shipped with Solaris.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:


       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).   ATTRIBUTE  TYPEATTRIBUTE   VALUE   AvailabilitySUNWckr
       Interface StabilityEvolving


SEE ALSO
       add_drv(1M),      rem_drv(1M),      update_drv(1M),     driver.conf(4),
       attributes(5), fcp(7D), ifp(7D), scsi_vhci(7D), sd(7D), sf(7D), st(7D),
       scsi_ifgetcap(9F), scsi_init_pkt(9F), scsi_transport(9F)

       Writing Device Drivers

       ANS X3T9.2/82-2 SMALL COMPUTER SYSTEM INTERFACE (SCSI-1)

       ANS X3T9.2/375D Small Computer System Interface - 2 (SCSI-2)

       ANS X3T10/994D SCSI-3 Architecture Model (SAM)

       IEEE 1275 SCSI Target Device Binding

NOTES
       With  driver.conf(4)  configuration, you need to ensure that the target
       and lun values claimed by your  target  driver  do  not  conflict  with
       existing  target drivers on the system. For example, if the target is a
       direct access device, the standard sd.conf file usually makes sd  claim
       it before any other driver has a chance to probe it.



SunOS 5.10                        26 Sep 2004                          scsi(4)