From: NORLMN::EVERHART 19-JUL-1996 11:45:55.42 To: STAR::ST_LAURENT,STAR::COUGHLAN CC: EVERHART Subj: Status From: Glenn C. Everhart Subj: July status 1. In reviewing the other interfaces to dkdriver, and after a small bit of testing, I have concluded that a modification to the switching layer is needed for most general operation. What I will do is use these entries to maintain a separate IRP queue for the switching layer, above the dkdriver/dudriver layer, so that I can ensure that in all cases, an IRP passing to one of the paths below the switch layer passes through the switch code which will relocate it correctly. By capturing start-io, pending-io, and mount verify points, and having control at posting time, I can do this readily and ensure that dkdriver or dudriver cannot pull packets off the queue which have not been processed. The code mods are small but significant in that it involves requeueing the I/O (or calling the appropriate init routine) symmetrically now for primary and secondary paths (however many secondaries there are...the code is not particularly specialized to two.) Thus it will become clearer and more symmetric. There are a few instructions needed for the queue handling that get added to the primary path (which were in the secondary already) but one cannot do switching without some switch point. I have not had time to write this all up, nor to get all the coding finished at this time, since I have been working on other dkdriver and mkdriver fixes and on the "two device names" fixups a bit too much to get to this. However, I will do so. The basic logic will be simple to handle; pending-io will put IRPs on the switching queue and the start-io intercept will pull them from there, or insert them at need (since the rest of VMS won't realize this is going on, nor does it need to). The dkdriver queue (or the dudriver queue) will look and be normal, but will contain nothing that has not passed through the switch code, which in general will act as a short detour to moving IRPs into the dk queue. Some internal switching will allow the pending IO calls of called drivers to take place with their own queues when the switch layer sends a packet on. Similarly, altstart will go through the switching layer first, then be vectored to the subordinate altstart. The mount verify start / stop entries requeue IRPs when mount verify is run, which need to go to the real input queue so they can wind up where they must, and on end of mount verify we must ensure that things start correctly by being sure that we get the first IRP onto the right queue. The foregoing covers what has to be done technically. I have worked up a more complete writeup of the switching layer, but it needs to have this material added. I hope to do so in fairly short order. My document is much more general than at the first review of it, and more readily understood, as well as adding many issues of non-HSZ multipath to its discusseion. However I plan to have a shorter problem statement (like some John Hallyburton has done) and investigation report done from the Digital template which will leave out most of the internals detail; this is evidently confusing and belongs in a separate document. I expect to add the information here to the documentation and then have a review, rather than awaiting further tests. The detail can and should be present for a design review once the investigation review is done. 2. I have a number of fixes to problems in DKdriver (and some corresponding ones done for mkdriver and dkmk.c which need to be tested and checked) which will be reviewed (for dk) later today. Coding and a bit of test for the dual path problem (so far, so good) is also done, but has been pushed back of the fixes to dkdriver (and the rest) for failure to check the status after various SPI$ commands. Glenn Everhart