passing miniport driver adapter context pointer to IRP

I am writing a NDIS miniport driver, and starts from the
DDK sample, Netvmini. I want to use the miniport driver
adapter context to store the state information and
incoming/outgoing packets. However, I do not know how IRP
(DeviceIoControl routines) can acess the adapter context.
I heard that I should store the adapter context pointer
under IRP->FileObject->FsContext when IRP_Create is run.
How can I do that? Should I store the context pointer
under the device extension of the device object created by
NdisMRegisterDevice?

Thanks,
Billy Ng.

bburgin
Mon Jan 12 16:04:31 CST 2004

------=_NextPart_0001_E9472F82
Content-Type: text/plain
Content-Transfer-Encoding: 7bit



Actually, I think the way you want to do this is store the FsContext from
the Create IRP in your adapter structure. You'll get the same context in
each IRP you receive -- in which case, you can compare that to the context
that you stored in your adapter context.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_E9472F82
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par
\par Actually, I think the way you want to do this is store the FsContext from the Create IRP in your adapter structure. You'll get the same context in each IRP you receive -- in which case, you can compare that to the context that you stored in your adapter context.
\par
\par Bryan S. Burgin
\par bburgin@microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_E9472F82--

Thomas
Mon Jan 12 16:12:44 CST 2004

The NDIS FAQ has some information on this topic. See the topic "How can I
access my NDIS miniport driver from a user-mode application?" at theURL:

http://www.ndis.com/faq/QA10290101.htm

Let's assume that you have already managed to store adapter context and
packets somewhere. The most common approach is to allocate a structure
(typically called "ADAPTER") for each miniport instance. Each ADAPTER
structure is typically stored in a linked-list with a global variable
serving as the adapter list head. Most often the ADAPT structure has fields
which are linked-list heads that are used to queue packets. (A driver is
really a "list-of-lists" machine...).

You need to be able to identify or "name" each ADAPTER instance. You can
probably use the handle given to you in MPInitialize as a unique "name" for
each ADAPTER structure. (You can probably think of alternatives to this
naming scheme...).

At this point you can take a look at the DDK NDISPROT sample or the
"Extending the PassThru NDIS IM Driver Sample - Part 2"
(http://www.wd-3.com). Both of these illustrate:

1.) The use of FsContext/FsContext2
2.) How to query or enumerate bindings.
3.) How to associate a user-mode handle with a specific binding.
4.) How a driver can identify an I/O operation targeted to a specific
ADAPTER.

and mode.

Of course, the "names" in these samples are different from yours. Your name
is just a HANDLE (or some other invention).

Nevertheless, the information that you need can be found by examining the
samples mentioned above.

Good luck,

Thomas F. Divine - DDK MVP
www.rawether.net - www.pcausa.com



"Billy Ng" <anonymous@discussions.microsoft.com> wrote in message
news:0a5301c3d922$339516b0$a601280a@phx.gbl...
> I am writing a NDIS miniport driver, and starts from the
> DDK sample, Netvmini. I want to use the miniport driver
> adapter context to store the state information and
> incoming/outgoing packets. However, I do not know how IRP
> (DeviceIoControl routines) can acess the adapter context.
> I heard that I should store the adapter context pointer
> under IRP->FileObject->FsContext when IRP_Create is run.
> How can I do that? Should I store the context pointer
> under the device extension of the device object created by
> NdisMRegisterDevice?
>
> Thanks,
> Billy Ng.