This is one of the old Unix-OSD Group Messages that John Gallant sent to me for posting on the SCSI BBS. The date reflects when he sent it to me, not the original message date. John Lohmeyer ---------------------------------------------------------------------------- Date: Thu, 4 Jan 90 17:13:23 -0500 From: "John A. Gallant UEG" Message-Id: <9001042213.AA25516@abyss.zk3.dec.com> To: jlohmeye@entec.wichita.ncr.com Subject: Darryl's Unix OSD document Hello All: Sorry for the lateness of this mail, but perhaps we can start some discussion before the CAM meeting. Remember we did say that we wanted to start some e-mail discussions, a few months ago :-). I have a couple of issues and questions to raise about the initialization parts of Darryl's proposal. Overall I am in agreement with what Darryl has. [All of Darryl's included text is indicated by a ">" at the beginning of the line. Do we all feel this is a good convention to follow ?. It follows the usenet posting convention. JAG]. >Here is a proposed base for our group's OSD section efforts. > > --Darryl Richman, Interactive Systems Corp. > > 6.5 UNIX_Operating_System > > The UNIX CAM consists of 3 sets of drivers: 1) peripheral > drivers that are device class specific, 2) a configuration > driver and the XPT, and 3) SIMs that are HBA specific. Each > member of these sets is treated as a UNIX driver and is > linked into the kernel. The XPT and configuration driver > are OS vendor specific; other drivers may come from any > source. > > At kernel configuration and link time, a static table of > included peripheral drivers and SIMs is created and linked > into the configuration driver. A static table is definitly needed for the configuration/XPT/SIM points. They are going to need knowledge of how to contact one another in a non link time manor. However a problem with the peripheral drivers will occur when you have BSD based systems vs system V. It probably will be good to have entry/or other points for the drivers within this table. Perhaps a default call back or fatal error entry point, or simply a reset/restore point, I'm not sure just what at this time. > 6.5.1 Initialization > > At system startup, the configuration driver's init function > is run from the ioinit array. ....................... With BSD based there no "ioinit" array, I belive that this is a sys V concept, where there is one init routine per driver. In BSD systems there are the triplet routines probe/attach/slave. These are called via the configuration magic higher up in the Kernel. > ............................. It calls across the CAM > interface, through the XPT, to each SIM in turn, allowing > them to initialize. The configuration driver obtains > information about each SIM, HBA, and target device detected > and maintains a table of these devices. Note that > interrupts are disabled during the ioinit phase. I would expect them to be turned off during all the setup and init phases. > After all of the SIMs have initialized and the configuration > table has been filled in, the configuration driver invokes > the initialization routines for each peripheral driver. > This allows them to determine what devices are known and > make appropriate memory allocations and resource requests of > the XPT. This is were the I have the biggest problem. With BSD based systems the configuration magic sets up a number of data structures that are used by a lot of the io/fs utilities. Would this mean that these BSD based systems would have to minic what the conf code is doing in the configuration/XPT init handlers ? I think that what we had originaly discussed back in November(?), is still valid. The plan was that the first call to the XPT to initialize itself from any peripheral driver would kick off the configuration driver/XPT/SIM sequence. Once the sequence had finished that initial call from the peripheral driver would be completed. Using the ioinit[] array scheme the first call would come from the configuration driver. In the BSD/configuraion scheme, the sequence of what peripheral drivers is called before another is not known, so any peripheral driver could be called before the configuration driver. I know that this is a little complicated but it does remove any constraints on a predefined initialization sequence. > > 6.5.2 Accessing_the_XPT > > 6.5.2.1 From_the_Peripheral_Driver > > All CAM requests to the XPT are placed through a single > function call: void XPTaction(CCB *). All returned status > information is obtained at the callback point via the CAM > and SCSI status fields. > > The XPT also provides functions for obtaining resources for > the peripheral driver. These are: allocate and free ccb, > allocate and free cdb, allocate and free dma. [Note that > these are not specified. The completed document will have > to include definitions of these functions.] > > 6.5.2.2 From_the_SIM > > The SIMs obtain requests from the XPT as they are passed > across from the peripheral driver, via a routine included in > the SIM's configuration information. The field in the > configuration table is declared as > void (* SIMaction)(CCB *). The XPT does not modify ccbs or > cdbs. The XPT must intercept those ccbs which must be > redirected to the configuration driver (i.e., Path Inquiry, > Get Device Type, and Set Device Type). What worries me is that we have spent a lot of work making sure that the SIMs do not have to worry about what is contained in a CDB. Now we have the XPT scanning each CCB for particular commands that need to be routed to another driver, even though the configuration driver "works for the XPT". Unfortunatly I don't have another way to handle this problem. I do however have an possible way to make the interception of CCBs a little simpler. What about having the commands that are particular to the configuration driver/ XPT be within a range of values or have a particular bit, msb, set to signify special routing is needed. This may be too much work considering that we only have about 7 commands, but what if the list gets much larger ? How many cascading if() statements become too many ? Or how many angels can dance on the head of a pin .. ? Oops sorry I became carried away :-). > 6.5.3 Callback_on_Completion > > The callback field in the ccb is a structure that is > platform specific, but always contains at least a callback > function pointer, named cbfcnp, and declared as > void (*cbfcnp)(CCB *). It is allowed for the cbfcnp to > contain NULL, in which case no callback operation is > performed. Do we want to look at what the SIM does after the CCB is complete? I would expect that it would handle the next CCB on its queue. But what if its queue is empty, do we want it to call back to the XPT to allow another SIM to do something ? Or would it be better to have each SIM only handle its particular queue, and have the other SIMs on interrupts handle theirs? Could we get into a dead lock condition where everybody is waiting for an event to start off their queue ? John A. Gallant jag@decvax.dec.com Senior Software Engineer - Ultrix Engineering Group Digitial Equipment Corp. (603) 881-2472 "A beautiful theory, killed by a nasty, ugly, little fact." Thomas H. Huxly