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:16:01 -0500 From: "John A. Gallant UEG" Message-Id: <9001042216.AA25681@abyss.zk3.dec.com> To: jlohmeye@entec.wichita.ncr.com Subject: re: Darryl's Unix OSD document jag@decvax.dec.com writes: "darryl@ism780c.isc.com writes: "> 6.5 UNIX_Operating_System ">[...] "> 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. I'd prefer to see that the table be kept simple, but if that is not possible, I'd like to have the simple part of it mandatory and let vendors specify optional extras. They own the configuration driver and XPT anyhow. "> 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. Pardon me. I must admit to having little knowledge of the internals of BSD, and I'm sure that my Sys V experience is showing where it was not intended. Because of this, perhaps it would help if you could give a brief overview of the init time actions in a BSD kernel; to make it fair, here's a quick description of Sys V: After booting, the kernel enters main(). Interrupts are disabled at this point. When the kernel was linked, two tables of routines were created: io_init[] and io_start[]. (These are constructed mechanically by idconfig, which looks into the mdevice file for each driver and determines if it has an init and/or start routine, and builds the names as "prefix"init and "prefix"start, from the "prefix" specified in mdevice.) The entries are in mdevice file order, but I don't think that there's any guarantee that will always be true. While interrupts are off, each entry in the io_init[] array is called. Then interrupts are turned on, some copyright stuff is printed, and each routine in io_start[] is called. After this point, normal operation is expected. "> ............................. 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. Yes. Also, we should reword these paragraphs so that io_init is not used. We need to come up with some terminology that satisfies both Sys V and BSD. Can you suggest something, John? "> 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 don't see that it is necessary since the configurator will have all the knowledge that was necessary to construct the driver/SIM table. " 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. I'm not sure I understand exactly what distinction you are trying to make here. The two proposals look very similar in functionality. I chose mine because I wanted to make the configuration driver available as a separate entity that would be available to do dynamic loading and unloading of drivers. Perhaps it is my Sys V myopia again, but I had intended that none of the other drivers or SIM modules would be called out of the ioinit[] array; instead, by giving responsibility for the whole subsystem's initialization to the configuration driver, we can also gain some control and order the initialization process, if that is useful. For example, when performing an installation on a PC, I might want to ignore most devices and concentrate on my root disk; I could use the configuration driver to control this. "> 6.5.2 Accessing_the_XPT "> [...] "> 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 :-). 42. ;-) Surely a table of routing codes could reduce the cost to O(1) in checking for CAM commands vs. SCSI commands. "> 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 ? This is an important point. For good performance, the SIM must give up control quickly after completing a CCB; otherwise it is possible to hog the system for one HBA over others. As far as deadlock goes, the SIM is responsible for watching the timeout value for each CDB. This may require it to set a callout routine for the minimum timeout value in its queue. --Darryl Richman