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" <szubowicz@star.enet.dec.com>
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.