I’m in the process of porting an NT4 driver model to WDM/2000 and would like
to “improve” the unknown interrupt logic in my ISR. “Unknown interrupt” in
this case means it’s a legitimate interrupt, but the volatile data
associated with the interrupt needs to be queued for a while until a user
requests it. We call it “default target handling”, but I doubt many others
would grok that. 
Currently, during driver initialization and startup, I build 2 lists, free
and holding, and allocate a fixed number of queue items from NonPaged
memory, hanging them on the free list. When the default target handler
function is called it determines if the request should be queued, fetches
the next item from the free queue, saves the volatile data in the queue and
hangs it on the holding queue. A GET_NEXT_DESCRIPTOR request from the user
searches the holding queue for the proper request, removes the proper item
from the holding queue, burns the data, and returns the item to the free
queue. Queue management, using this method, has been a royal bitch, and what
I would like to do is use lookaside lists.
For one thing, the current method tends to be restrictive in that the same
pending queue, with free/holding lists service all sub-addresses which then
share all of the pre-allocated free/holding items. What I would like to do
is allocate a Lookaside list per sub-address (up to 256). Using zones, I
believe this could be done, but zones are obsolete now, and lookaside lists
allocation and freeing specifically state IRQL <= DISPATCH_LEVEL. I would be
allocating a chunk of memory from the free list at DIRQL. What I was
thinking was, that if I promise to never call ExAllocatePool at >
DISPATCH_LEVEL, which is possible since my allocation/free routines would
check for that, could I use lookaside lists at DIRQL? House keeping such as
increasing/decreasing Lookaside list allocation would be done at <= D_L
through either a periodic thread or a Dpc.
Gary