Tim,
Not if you manage your own queues and do not use StartIo.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Timothy A. Johns [mailto:xxxxx@driverdev.com]
Sent: Friday, August 17, 2001 6:14 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Dispatch IRQL value
Mark,
_Much in the same fashion that NT != VMS, ULONG != PVOID.
Slightly less depraved/more portable to 64 bits than the suggestion below,
is to use Birp->Tail.Overlay.DriverContext[0] to store the work item instead
of the IoStatus.Information. Beware of using that field, however, if you’re
queueing IRPs - it’s part of a union that’s used for both purposes
(driver-specific data and IRP queues).
For example, if in the example below you were tempted to put the IRP into a
queue so the work item could handle many of them when it finally got a
chance to run (perhaps a reasonable thing to do), you’d be overwriting your
queue pointer when you assigned the work item into the IRP.
Somebody apparently forgot to explain all that to the 98 WDM team for the
PnP IRPs, however…
-Tim
Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Friday, August 17, 2001 4:44 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Dispatch IRQL value
If your dispatch routine is called at > PASSIVE_LEVEL but you need to
perform some foul and depraved act that requires you to be at
PASSIVE_LEVEL then you need a worker thread that always runs at
PASSIVE_LEVEL to be your minion and do your bidding.
As in:
NTSTATUS
FrobnitzDispatchDeviceDoodle(DeviceObject, Birp)
{
… The usual crapola here
if (KeGetCurrentIrql() != PASSIVE_LEVEL) {
PIO_WORKITEM minion = IoAllocateWorkItem(DeviceObject);
if (minion == NULL) {
//
// notify the caller that the system is going to
// crash in a moment
//
Birp->IoStatus.Status = STATUS_WE_ARE_DOOMED;
IoCompleteRequest(Birp, IO_NO_INCREMENT);
return STATUS_WE_ARE_DOOMED;
}
Birp->IoStatus.Information = minion; // I said this was
depraved
IoMarkIrpPending(Birp);
IoQueueWorkItem(minion, FrobnitzWorkerDepravedAct,
CriticalWorkQueue, Birp);
return STATUS_PENDING;
}
//
// otherwise just do your depraved act here
//
… Whatever
return STATUS_SOMETHING_OR_OTHER;
}
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Justin
> Schoenwald
> Sent: Friday, August 17, 2001 6:29 PM
> To: NT Developers Interest List
> Subject: [ntdev] Dispatch IRQL value
>
>
> Hello ntdevs,
>
> On NT4 I called MmAllocateContiguousMemory() in response to
> an IRP_MJ_DEVICE_CONTROL call. It’s a problem to me that on
> Win2K this doesn’t work (MmAllocateContiguousMemory returns null).
>
> I see that Win2K MmAllocateContiguousMemory must be called at
> IRQL PASSIVE_LEVEL, so I guess that’s the difference.
>
> My driver is monolithic, so is that a highest-level or
> lowest-level driver?
> From Win2k docs:
>
> ---------------------------- begin doc
> Most drivers’ Dispatch routines are called in an arbitrary
> thread context at IRQL PASSIVE_LEVEL, with the following exceptions:
>
> Any highest-level driver’s Dispatch routines are called in
> the context of the thread that originated the I/O request,
> which is commonly a user-mode application thread.
> In other words, the Dispatch routines of file system drivers
> and other highest-level drivers are called in a nonarbitrary
> thread context at IRQL PASSIVE_LEVEL.
>
> The DispatchRead, DispatchWrite, and DispatchDeviceControl
> routines of lowest-level device drivers and of intermediate
> drivers layered above them in the system paging path, can be
> called at IRQL APC_LEVEL and in an arbitrary thread context.
> ---------------------------- end doc
>
> So I guess my DispatchDeviceControl routine is being called
> at IRQL APC_LEVEL, but why? (The only application to use it
> is my own). Is there a way around this?
>
> [I’d like to save someone the time it takes to criticize
\> allocating non-paged memory outside of DriverEntry(). Its
\> only use is for extremely specialized hardware and controlled
\> environments.]
>
> Thank you all (generally, for list contents),
> Justin
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
You are currently subscribed to ntdev as: xxxxx@driverdev.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com_