From: SMTP%"szubowicz@star.enet.dec.com" 1-SEP-1993 15:01:16.14 To: EVERHART CC: Subj: RE: Other driver techniques Message-Id: <9309011901.AA15876@us3rmc.bb.dec.com> Date: Wed, 1 Sep 93 12:01:30 PDT From: "Lenny Szubowicz, OpenVMS Engineering, ZKO3-4/T42" To: everhart@arisia.gce.com Cc: schafer@xlib.enet.dec.com, msherlock@jareth.enet.dec.com, szubowicz@star.enet.dec.com Apparently-To: everhart@arisia.gce.com Subject: RE: Other driver techniques Glenn, I'll try to address your initial questions. > First, I have some driver code that puts a system address in IRP$L_PID > so it currently (phase 1) gets JSBd to from IOPOST. Can you tell me > if the routine will now be called as a normal style entry when I do > this, or will it remain a JSB? This has not changed. However, we ought to consider supporting both the current JSB interface (where R5 = IRP) and a callable interface for special I/O post-processing routines: void post_routine (IRP *irp); We should be able to support both styles of interfaces transparently just like we do with fork routines and special kernel AST routines. > special kernel ASTs? Are they called by procedure now, or are they > still JSB - called? Special kernel AST routines can either use the traditional JSB interface or the new call interface just like fork routines. We neglected to document this interface: void special_kast (PCB *pcb, ACB *acb); > Second, I have some other code that reissues the FDT calls a bit > lower on the stack by duplicating the loop in the qio processing. > Would I be correct in assuming that the loop is not changed much, > but that the current JSB becomes a procedure call? FDT processing is the area that has changed the most. The format of the FDT function dispatch table is very different in step 2. Prior to step 2 the FDT dispatch structure was an unterminated list of bit masks and pointers. In step 2 the FDT structure is a fixed length structure that contains a vector of 64 pointers to FDT routines. Each vector entry corresponds to one of the possible 64 function code values (the low-order 6-bits of the $QIO function code value, which excludes the function code modifiers). Thus, the "infinite loop" in SYSQIOREQ is now replaced with a direct call to the single applicable FDT routine. The step 1 mechanism relied on usage of the "RET under JSB" mechanism to effect a "poor man's unwind" out of the infinite loop in SYSQIOREQ back to the system service dispatcher. We needed to get away from this mechanism since in general it is not available to higher level languages. Thanks for your interest and comments. -Lenny Szubowicz.