[Info-vax] Volatile, was: Re: yet another sys$qiow question

[Johnny Billquist]

On 2015-08-21 17:05, "VAXman- "@SendSpamHere.ORG wrote:
> In article <55d7365d$0$3309$b1db1813$145976f0 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
>> On 15-08-21 09:36, "VAXman- "@SendSpamHere.ORG wrote:
>>
>>> may need to wait in which case, the driver "forks".  Once that thing that
>>> the driver has been waiting for has occurred, the driver code is revisited
>>> by the OS dispatching to where the driver forked.  Context is saved in the
>>> fork block to allow the driver to pick up where it left off.
>>
>> Thanks. So when an IO (device level) completes, the driver continues
>> where it left off.  Does it have to explicitely re-establish context by
>> reloading the informtion that was saved at fork time, or is that all
>> done automatically ?
>>
>> In other words, does the driver continue as if nothing had happened
>> between the fork and the next instruction ? Or upon completion of the
>> fork, does it do work to restore context for that particular IO ?
>
> Pretty much so.  Typically, the driver FORKs at a higher IPL and then, it
> continues where it left off at a lower IPL.  Thus, interrupts, typically
> at high IPL, can be services and then, when the OS drops IPL, it handles
> the FORK.
>
>
>
>> Is it fair to state that the context that is saved when doing the fork
>> is not volatile ? (aka: a blob of data that won't change during the time
>> of the fork ?)
>
> The FKB would be the context.  It's usually contains the fork lock, R3/R4
> (typically, in driver context, this would be the IRP and PCB/KTB, or some
> other address of driver relevant structures), and the IPL/Spinlock.  The
> only thing that would/could change would be FLINK/BLINK addresses in the
> FKB due to other FKB queueing.

If you had said R4/R5, then this would have been identical to RSX. :-)

	Johnny