Hi, Glenn,

We'll have more details in our specs in about a month or so.

In the meantime:

You have to distinguish between server side and client side.  On the client 
side, we intercept all IRPs before they get to start I/O for the served device.
The sources of these IRPs are FDT, pager/swapper, etc. -- i.e., anything that 
calls the start I/O entry point, either through IOC_STD$INITIATE or via the 
DDT$PS_START2 entry point.  The only code in DKDRIVER executed on the client
is the FDT routines; other code never gets control (or that's the idea, at any 
rate).

On the server, we don't intercept start I/O, and QIOserver's KSERVER is merely 
one more source of IRPs, like anything else.  QIOserver doesn't care what 
DKDRIVER does internally to manage the IRPs on the server.

Where it will get tricky is in dealing with your hooks into mount verify on the 
client -- duplicating the work you did in DKDRIVER somehow in our KCLIENT.
There won't be any DKDRIVER code executing on the client that knows anything 
about mount verify or the other hooks to deal with switching.  I haven't had
the chance to look into this problem yet (I'm still buried in the bowels of 
INIT_IO_DB and NISCA_BTDRIVER, looking for QIOserver hooks), but I'll get to it 
shortly.

John
-------------------------------------------------------------------------------

John -
Reading your pp.

In sect. 6.1.2 I see you mention intercept of start-io. I presume this
is for a driver that alwasy calls its start-io, not one like dkdriver
that loops around?

My test code needed to set the swapio bit so a disk'd go into MV
underneath most cleanly (I clear it when I get ready to really post
it). Still I need to intercept pending io too. I believe that the
business about not having too many pending I/O was a partial
misdirection...the real loop was that pending I/O got sent to
startio by the fake-MV error code I had hacked into dkdriver or
vddriver with never a chance to finish anything. Partly a test
artifact, in other words...but a stress case that should be handled
anyway.

As for IRPEs, dammit we just HAVE to get an irp-based arg stack
in there for "most of the time" so's to avoid a huge overhead
hit.
glenn