home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / periphs / scsi / 6270 < prev    next >
Encoding:
Text File  |  1992-12-29  |  5.1 KB  |  98 lines
  1. Newsgroups: comp.periphs.scsi
  2. Path: sparky!uunet!noc.near.net!mv!chillon!decvax.dec.com!decvax.DEC.COM!jag
  3. From: jag@decvax.DEC.COM (John A. Gallant UEG)
  4. Subject: Re: SCSI/CAM Request For Information
  5. Message-ID: <1992Dec29.154603.18191@decvax.dec.com>
  6. Sender: usenet@decvax.dec.com (Usenet News System)
  7. Nntp-Posting-Host: witsend.zk3.dec.com
  8. Reply-To: jag@zk3.dec.com
  9. Organization: OSF Engineering, Digital Equipment Corp.
  10. References:  <1992Dec16.191430.1667@pt.com>
  11. Date: Tue, 29 Dec 1992 15:46:03 GMT
  12. Lines: 84
  13.  
  14. In article <1992Dec16.191430.1667@pt.com>, rcw@pt.com (Ray Ward) writes:
  15. >I am working on a SCSI driver for the NCR53C720 product.  It is a dual
  16. >channel board.  I have read the SCSI/CAM specification and think that
  17. >would be the way to implement a driver.  I am doing the driver on a
  18. >System VR3 platform.  I have the following questions regarding the init
  19. >portion of the modules.
  20. >
  21. >1)  The spec talks about a configuration_driver().  What is the format of
  22. >    this and how is it invoked (directly from the kernel or from the XPT)?
  23.  
  24.     During this part of the CAM committee work we could not cast in stone
  25. the proper initialization sequence for all of the various OSD sections or
  26. even within the SVR* and B*D camps.  We agreed that there needed to be 
  27. a single "driver" phesudo or other wise, that needed to be responsible for
  28. the configuration/initialization of all the SIMs and XPT modules.  This
  29. module was called the configuration module and it was the responsibilty
  30. of the system vendor to provide this with their CAM implementation.
  31.  
  32.     There was no way, that we could guarantee, that would ensure that 
  33. the configuration driver would be called before any of the SIMs or 
  34. any of the peripheral device drivers.  There was the requirement that
  35. the peripheral device drivers call the xpt_init() routine all the time.
  36. The SIM side of things is left to the system vendor. 
  37.  
  38.     The interaction between the configuration driver and XPT should be
  39. straight forward.  If the configuration driver is initialized then it
  40. would initialize the XPT, and if the xpt_init() routine is called and
  41. the XPT is not initialized yet it could call the configuration driver.
  42.  
  43. >    This module sets up the cam_edt[] table.  How is the relationship
  44. >    between the physical device parameters (SCSI ID, device type, etc)
  45. >    and the logical device name made (is the information contained in
  46. >    the cam_edt[] and if so, who sets it up?)?  How does the
  47. >    configuration_driver() know about the existence of any SIM's?
  48.  
  49.     The EDT structure is accessed using the Bus/Target/LUN information
  50. only.  It should only contain any INQUIRY information, and possably the
  51. Async callback information.  Any mapping between the /dev/* and SCSI
  52. Bus/Target/LUN is totally up to the peripheral device driver and not 
  53. the SIM.  The SIM only deals with the Bus/Target/LUN information.
  54.  
  55.     The configuration driver has two ways, there are others, that it would
  56. know about SIMs.  It can use the Path Inquiry CCB to determin how many
  57. SIMs are in the XPTs table and then call each possible one to get it 
  58. setup.  This would require a static table of SIM_ENTRYs that the XPT
  59. knows about.  The other way, depending on how the OS does thing, the 
  60. SIMs could have their own "configuration point" that also inturn calls
  61. the configuration driver to complete the initialization.
  62.  
  63. >2)  How does the peripheral driver or the XPT access the cam_edt[] or the
  64. >    cam_conftbl[] (are they both global)?
  65.  
  66.     They are *NOT* global to the peripheral device drivers.  The GET/SET
  67. device type CCBs are to be used by the peripheral device drivers.  The 
  68. format and content of these structures are described but the system vendor
  69. that provides the XPT and configuration driver has the option to do
  70. what ever is necessary for their implementation.  For example our
  71. configuration driver handles the GET/SET CCBs and the XPT deals with the
  72. async callback handling.  For both of these modules the cam_edt[] is 
  73. common but that is between "consenting modules".  The cam_conftbl[] 
  74. is also not global to non XPT/configuration driver modules.
  75.  
  76. >3)  When performing the auto-scan, is the device existence tested for at
  77. >    the SIM level or does the XPT set up a Test Unit Ready CCB and issue
  78. >    it to the SIM?  Is this information passed to the configuration_driver()
  79. >    or is the cam_edt[] writable by both the XPT and SIM?
  80.  
  81.     First of all the auto-scan should only use the INQUIRY CDB, any other
  82. SCSI command will affect any pending Unit Attention conditions that the
  83. devices may have.  Loosing the pending Unit Attention can have a
  84. disasterous effect on tape devices and their drivers.  According to the
  85. CAM spec we wanted to have a single bus scan done on the system.  The 
  86. logical place was within the XPT/configuration driver modules.  This
  87. way the SIMs would not have to worry about having to create CCBs and also
  88. inturn deal with understanding the data.
  89.  
  90. -- 
  91. John A. Gallant                                jag@zk3.dec.com
  92. Software Engineer - OSF Engineering Group
  93. Digital Equipment Corp. (603) 881-2472
  94.  
  95.         In the common people there is no wisdom, no penetration, no
  96.         power of judgment.
  97.     Marcus Cicero
  98.