To: st_laurent,coughlan,croll Subj: switch progress Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: I am pleased to be able to announce that 2 path switching at least of VD units has worked with swdriver. Current code sources are in scsi$work:[everhart]sw*.*, if you want to look. I have noted a number of places where the code can be cleaned up therein, and know of more, but this at least contains the functions now for moving in and out of MVerify on more than one path. At this level, btw, nothing is specialized to SCSI. There is specialization to 2 paths, but nothing essential. Note that for correct operation you must use the io_routines.exe in scsi$work:[everhart] (built for Gryphon x6c7). The sources of the changed pieces (sysqioreq.mar and iosubnpag.mar) are in scsi$work:[everhart] as well. (Also a version of the mods for the Raven sysqioreq is in there too as SYSQIOREQGERAVEN.MAR. ) Notwithstanding the fact that this version is working at least on vd units (I test on dk next) (scsi$work:[everhart]vdd64.zip has the vddriver sources), the fact that considerable fiddling is necessary because now instead of catching an IRP at start_io (as was possible in VMS 6.1 and before) I have to catch it at either start_io or pending_io. This made it necessary to use an entirely separate queue for all inputs and to have checks all over the place to see whether I've already handled the IRP changes necessary to have the IRP on the currently selected path. Because I want this to be a low overhead operation, I will propose the following mods: 1. DDTAB should have a new entry point which will be passed through by ALL IRPs but which will NOT be a JSB or CALL entry. Rather, it will just be a label beyond the startio entry point somewhere. Then a convention would be established that drivers needing to loop back and not wanting to blow kernel stack (dkdriver does this) will loop back via this entry point in the DDTAB (in fact, going via the ddtab entry). Drivers with this entry would not need all the pending io catching or separate I/O queue, and other Alpha drivers that need to loop back and have intermittent stack problems could be retrofitted in this way without prejudice to intercepts. 2. REQCOM might want to be modified to use this also. 3. I'll propose adding a stack to each IRP after all that is currently there. At present, intercept apps have to allocate their own storage (or have the IRP extended as shadowing has), usually in pool, for context they need to alter. While they will still need to be able to do this if a short IRP is made someplace, it will be a performance win to have a stack (and a couple pointers) in an IRP where intercepts can push and pop context. This will facilitate formally describing an IO streams interface a la unix or nt, MIGHT facilitate use of NT drivers someday (kind of a conceivable side benefit), and will certainly facilitate 3rd party extensions as well as facilitating more orderly I/O layering within VMS itself. The foregoing is intended to be partly a heads up on what I've been thinking of. I've run these latter ideas by Lenny briefly and was not totally shot down, though he's concerned with backward compatibility. Glenn Everhart 6-Dec-1996