NDIS drivers and device extensions

NTDEV
1

According to MSDN, NDIS drivers that use NdisMRegisterDevice cannot use the
device extension field in the device object.

What should one use instead then? I’m reluctant to use a global variable to
store the necessary data…

The thing is that I want to share data between some of the IOCTL dispatch
routines and the MiniportSendPackets() function. I could have done this
easily if I had access to the device extension field, but unfortunately I do
not.

Oh, and this is a miniport driver, if you hadn’t spotted that yet :slight_smile:

–Søren

2

S?ren,

Are you trying to create a device object for every miniport (adapter
instance) or just a single device object for the ‘driver’?
NdisMRegisterDevice() is more often used as a way of creating a ‘control
device’ associated with the driver and not individual auxilary device
objects associated with each miniport adapter.

If you only need one for the driver, global data is no different.

If you really are trying to create a device object for each adapter, then
two things come to mind:

  1. You potentially have the wrong model of interaction. Perhaps custom
    OIDs would be a better choice and communicate to the miniport adapters via
    something like NDISUIO (NDISPROT in the DDK) or via WMI and avoid the
    auxilary device altogether.

  2. You are convinced this is the right thing. In that case, you could
    stick the DeviceObject pointer in the ADAPTER structure and scan the list of
    adapter structures looking for a match on each IRP submitted. In other
    words, lookup the appropriate adapter with each request. Rather a pain and
    some might argue inefficient but RW locks (instead of the veritable
    spinlock) protecting the global list of ADAPTERs can help a bit.

I will refrain from endorsing the ever popular ‘hijack’ NDIS’s own PDO for
the miniport or other bits of NDIS-internals-aware suggestions. I’m sure
they will surface, however. If you really need to get every ounce of
performance out of a DeviceIOControl() interface to an NDIS Miniport driver,
you should keep reading through (1) above until you settle on ‘custom
protocol’ as the solution.

Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, January 07, 2006 4:04 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS drivers and device extensions

According to MSDN, NDIS drivers that use NdisMRegisterDevice cannot use the
device extension field in the device object.

What should one use instead then? I’m reluctant to use a global variable to
store the necessary data…

The thing is that I want to share data between some of the IOCTL dispatch
routines and the MiniportSendPackets() function. I could have done this
easily if I had access to the device extension field, but unfortunately I do
not.

Oh, and this is a miniport driver, if you hadn’t spotted that yet :slight_smile:

–S?ren

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@msn.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

3

Thanks for the elaborate reply.

At this stage I only need a single device object as there should only be one
adapter installed at a time.

I’m currently using the adapter context as storage for send queues, locks,
etc… Should I just make a global pointer to this structure which can be
read from the dispatch routines or would you recommend a ‘smoother’ way? It
is potentially dangerous if a dispatch routine tries to access the pointer
when the adapter is shutting down and hence is freeing its resources…

I’m still new to driver development though, so every advice you can give is
greatly appreciated!

Thanks,

“David R. Cattley” wrote in message news:xxxxx@ntdev…
Søren,

Are you trying to create a device object for every miniport (adapter
instance) or just a single device object for the ‘driver’?
NdisMRegisterDevice() is more often used as a way of creating a ‘control
device’ associated with the driver and not individual auxilary device
objects associated with each miniport adapter.

If you only need one for the driver, global data is no different.

If you really are trying to create a device object for each adapter, then
two things come to mind:

1. You potentially have the wrong model of interaction. Perhaps custom
OIDs would be a better choice and communicate to the miniport adapters via
something like NDISUIO (NDISPROT in the DDK) or via WMI and avoid the
auxilary device altogether.

2. You are convinced this is the right thing. In that case, you could
stick the DeviceObject pointer in the ADAPTER structure and scan the list of
adapter structures looking for a match on each IRP submitted. In other
words, lookup the appropriate adapter with each request. Rather a pain and
some might argue inefficient but RW locks (instead of the veritable
spinlock) protecting the global list of ADAPTERs can help a bit.

I will refrain from endorsing the ever popular ‘hijack’ NDIS’s own PDO for
the miniport or other bits of NDIS-internals-aware suggestions. I’m sure
they will surface, however. If you really need to get every ounce of
performance out of a DeviceIOControl() interface to an NDIS Miniport driver,
you should keep reading through (1) above until you settle on ‘custom
protocol’ as the solution.

Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
Sent: Saturday, January 07, 2006 4:04 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS drivers and device extensions

According to MSDN, NDIS drivers that use NdisMRegisterDevice cannot use the
device extension field in the device object.

What should one use instead then? I’m reluctant to use a global variable to
store the necessary data…

The thing is that I want to share data between some of the IOCTL dispatch
routines and the MiniportSendPackets() function. I could have done this
easily if I had access to the device extension field, but unfortunately I do
not.

Oh, and this is a miniport driver, if you hadn’t spotted that yet :slight_smile:

–Søren

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@msn.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

4

S?ren,

Most of the sample Miniport drivers have a global ‘adapter list’ protectect
by a spinlock. The best way to protect the lifetime of an adapter structure
is to reference count it. Simply don’t complete the MiniportHalt() until
the reference count indicates that pending IRPs have completed (that
reference the adapter). Of course you need to prevent *new* requests from
being accepted if the adapter is being shutdown.

I strongly recommend you look into a custom OID and WMI as a way of
communicating with your miniport. All of the syncronization will be handled
by WMI and NDIS.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, January 07, 2006 7:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS drivers and device extensions

Thanks for the elaborate reply.

At this stage I only need a single device object as there should only be one
adapter installed at a time.

I’m currently using the adapter context as storage for send queues, locks,
etc… Should I just make a global pointer to this structure which can be
read from the dispatch routines or would you recommend a ‘smoother’ way? It
is potentially dangerous if a dispatch routine tries to access the pointer
when the adapter is shutting down and hence is freeing its resources…

I’m still new to driver development though, so every advice you can give is
greatly appreciated!

Thanks,

5

Sounds like an idea.

Regarding custom OIDs and the WMI it’s definitely something I will come back
to when I’ve become a little more confident with driver development. There’s
still a lot I haven’t dug into yet. WMI being one of them.

Thanks for the help.

“David R. Cattley” wrote in message news:xxxxx@ntdev…
Søren,

Most of the sample Miniport drivers have a global ‘adapter list’ protectect
by a spinlock. The best way to protect the lifetime of an adapter structure
is to reference count it. Simply don’t complete the MiniportHalt() until
the reference count indicates that pending IRPs have completed (that
reference the adapter). Of course you need to prevent new requests from
being accepted if the adapter is being shutdown.

I strongly recommend you look into a custom OID and WMI as a way of
communicating with your miniport. All of the syncronization will be handled
by WMI and NDIS.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
Sent: Saturday, January 07, 2006 7:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS drivers and device extensions

Thanks for the elaborate reply.

At this stage I only need a single device object as there should only be one
adapter installed at a time.

I’m currently using the adapter context as storage for send queues, locks,
etc… Should I just make a global pointer to this structure which can be
read from the dispatch routines or would you recommend a ‘smoother’ way? It
is potentially dangerous if a dispatch routine tries to access the pointer
when the adapter is shutting down and hence is freeing its resources…

I’m still new to driver development though, so every advice you can give is
greatly appreciated!

Thanks,

6

> According to MSDN, NDIS drivers that use NdisMRegisterDevice cannot use

the
device extension field in the device object.

What should one use instead then? I’m reluctant to use a global variable to
store the necessary data…

Why? This is the correct way. NdisMRegisterDevice creates the device which is
not associated with any miniport instance at all, you must do the association
yourself. So, global data is your friend.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

7

Yeah, I guess I’m just too colored from parts of application programming
where global data is considered the worst thing that could ever happen :slight_smile:

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> > According to MSDN, NDIS drivers that use NdisMRegisterDevice cannot use
> >the
> > device extension field in the device object.
> >
> > What should one use instead then? I’m reluctant to use a global variable
to
> > store the necessary data…
>
> Why? This is the correct way. NdisMRegisterDevice creates the device which
is
> not associated with any miniport instance at all, you must do the
association
> yourself. So, global data is your friend.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>

8

Soren Dreijer wrote:

Yeah, I guess I’m just too colored from parts of application programming
where global data is considered the worst thing that could ever happen :slight_smile:

No, only if it is used for information which is not global. Some data
truly IS global – one occurrance per system, shared amongst many
modules – and there is nothing wrong with using a global variable for
such information.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.