From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 27-MAR-1993 02:59:58.90
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: Driver Question

In article <1993Mar23.205833.1057@dragon.com>, cts@dragon.com writes:
>the
>question has been asked - could this idle function be incorporated at
>the driver in such a fashion that the driver would handle the idle
>message without being delayed by the other processing on the system.

(I answered this via mail a day or two ago, but forgot to post the reply)

Certainly.  Instead of having the process issue a QIO to send each idle message,
have it do a QIO which causes the driver to start sending idle messages.
If you want to get fancy a Pn parameter on the QIO could specify the delay.
Just set up a repeating TQE to cause a routine in the driver to get
called repeatedly.  When the TQE fires it can pass itself to the driver's
start I/O routine (or queue to the IRP wait queue if the driver is busy).

You don't even need to allocate a TQE from pool - just make it part of the
UCB extension.

When the "idle daemon" process goes away, the driver's cancel entry point will
get called, and this can be the signal to stop issuing the messages.

Most of the details on using TQEs from drivers are in [shameless plug follows!]
Lee's and my book on VMS driver techniques.

        --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG
Internet:  jeh@cmkrnl.com  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055

In article <1993Mar23.205833.1057@dragon.com>, cts@dragon.com writes:
> I have a system where a real time application drives custom hardware via
> a DRV11-W and a custom driver.
>
> One of the requirements of the system is that the hardware on the other
> end of the DRV11-W see an output several times a second to remain online.
> Right now, we're using a process to send out this "idle" message;  however,
> some of the other tasks that need to execute at a high priority (realtime,
> remember) sometimes prevent the idle task from doing its thing.
> Setting the idle task to a higher priority is not desirable;  the
> question has been asked - could this idle function be incorporated at
> the driver in such a fashion that the driver would handle the idle
> message without being delayed by the other processing on the system.
>
> One method suggested casually was capturing the IRP of an idle message,
> and continually queueing it up over and over again.  I'm uncomfortable
> with this approach.  Any ideas or suggestions from the net?
>
> --
> Charles T. Smith, Jr.                         | "Beam me up, Scotty, there's
 no
> VMS & Network Consulting                      |  intelligent life down
 here..."
> cts@dragon.com                                |
> {gatech,emory}!dragon!cts                     |
>

        --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG
Internet:  jeh@cmkrnl.com  Uucp: uunet!cmkrnl!jeh  CIS: 74140,2055