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

VAXman- at SendSpamHere.ORG VAXman- at SendSpamHere.ORG
Fri Aug 21 11:05:16 EDT 2015


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.

http://odl.sysworks.biz/disk$vaxdocdec953/decw$book/dy4yaa27.p107.decw$book
http://odl.sysworks.biz/disk$vaxdocjun963/decw$book/dy4yaa27.p139.decw$book

You really ought to get yourself a copy of the I&DSM (aka, "Book of Ruth")
and read it if you're truly interested in the nuances of OpenVMS internals.
I read and reread my copies so many times that, in the case of the Alpha
hard-bound I&DS, its pages fell out.  Fortunately, I have another copy. ;)
There's far too much to discuss in depth here on c.o.v. and the I&DSM is
the very best treatise on the subject.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.



More information about the Info-vax mailing list