[ofw] [RFC] [PATCH 1/2] work_queue: new abstraction for queuing work

[Sean Hefty]

>From the CM callback, you know that the EP is still valid and you can check to
>see if you have a disconnect request queued.  If so, you can remove it from the
>queue (so it can't be cancelled), and queue the work item using the request as
>context.  From the work item callback, reference the EP and QP (since they now
>could have been destroyed) based on the IOCTL parameters (just like you did
>when you first received the IRP), and assuming they're valid, move the QP.  You
>actually might not need to reference the EP, just the QP might do.

This is what the code does.  I just didn't realize that I could store additional
context in the IRP.

>No, you could have a pool of work items that you would pull from when you get
>the CM callback and need to queue it.  If the pool is empty, you could allocate
>new work items dynamically since that is valid operation at DISPATCH.

The work queue abstraction is the pool of work items.  I just don't allow the
pool to grow.  And since IO_WORKITEMs are opaque, maintaining them in a pool
requires additional structures around them.  You can't just have calls like:

IO_WORKITEM *PoolGet();
PoolPut(IO_WORKITEM *);
 
The only reason I even went down this path was based on the comments in the WDK.

- Sean