hi all,
I am in an NDIS miniport functional driver. And I need to find out the pci
function number and slot number from simply teh NDIS_HANDLE.
I cannot call NdisMGetDeviceProperty to get eh PDO handle else i would have
done it the usual way by calling IoGetDeviceProperty.
Is there any other way, WITHOUT the PDO to find out this information in an
NDIS miniport.
Pease note that I am on Vista, and the solution does not require to be
backward compatible.
–
You need the PDO. Why can’t you call NdisMGetDeviceProperty get the PDO
?
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Wednesday, July 11, 2007 3:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] pci function number and device number
hi all,
I am in an NDIS miniport functional driver. And I need to find out the
pci function number and slot number from simply teh NDIS_HANDLE.
I cannot call NdisMGetDeviceProperty to get eh PDO handle else i would
have done it the usual way by calling IoGetDeviceProperty.
Is there any other way, WITHOUT the PDO to find out this information in
an NDIS miniport.
Pease note that I am on Vista, and the solution does not require to be
backward compatible.
–
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Doron Holan wrote:
You need the PDO. Why can’t you call NdisMGetDeviceProperty
get the PDO?
Let me guess – he’s not “authorized”.
Well, one reason is I can get teh PDO, but even with the PDO, I will need to
call IoGet* functions to get eth data, but MS doesnt recommend calling Io*
functions in NDIS. So thought of doing a work around.
amitr0
On 7/12/07, Doron Holan wrote:
>
> You need the PDO. Why can’t you call NdisMGetDeviceProperty get the PDO
> ?
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Wednesday, July 11, 2007 3:18 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] pci function number and device number
>
>
>
> hi all,
>
>
>
> I am in an NDIS miniport functional driver. And I need to find out the pci
> function number and slot number from simply teh NDIS_HANDLE.
>
>
>
> I cannot call NdisMGetDeviceProperty to get eh PDO handle else i would
> have done it the usual way by calling IoGetDeviceProperty.
>
>
>
>
>
> Is there any other way, WITHOUT the PDO to find out this information in an
> NDIS miniport.
>
>
>
> Pease note that I am on Vista, and the solution does not require to be
> backward compatible.
>
>
>
>
>
> –
>
> - amitr0
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
Like many of the rules in WDK, you have to read between the lines. The
restriction against Io calls in NDIS to me reads like this (and
substitute Io for any non NDIS export)
* Use an NDIS function instead of an Io function if there is an
appropriate equivalent
* Do not use state changing Io functions b/c then NDIS will have
no idea what just happened
* In reality you can use Io functions in an NDIS driver b/c that
is exactly what an NDIS-WDM driver is
So, IMHO you can call IoGetDeviceProperty. It doesn’t have an NDIS
equivalent AFAIK, it does not change state and there are WDK NDIS
samples which make this call (see src\kmdf\ndisedge\60, ndiswdm.c).
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Wednesday, July 11, 2007 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] pci function number and device number
Well, one reason is I can get teh PDO, but even with the PDO, I will
need to call IoGet* functions to get eth data, but MS doesnt recommend
calling Io* functions in NDIS. So thought of doing a work around.
amitr0
On 7/12/07, Doron Holan wrote:
You need the PDO. Why can’t you call NdisMGetDeviceProperty get the PDO
?
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Wednesday, July 11, 2007 3:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] pci function number and device number
hi all,
I am in an NDIS miniport functional driver. And I need to find out the
pci function number and slot number from simply teh NDIS_HANDLE.
I cannot call NdisMGetDeviceProperty to get eh PDO handle else i would
have done it the usual way by calling IoGetDeviceProperty.
Is there any other way, WITHOUT the PDO to find out this information in
an NDIS miniport.
Pease note that I am on Vista, and the solution does not require to be
backward compatible.
–
- amitr0
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
- amitr0 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Ok thanks everyone.
amitr0
On 7/12/07, Doron Holan wrote:
>
> Like many of the rules in WDK, you have to read between the lines. The
> restriction against Io calls in NDIS to me reads like this (and substitute
> Io for any non NDIS export)
>
> ? Use an NDIS function instead of an Io function if there is an
> appropriate equivalent
>
> ? Do not use state changing Io functions b/c then NDIS will have
> no idea what just happened
>
> ? In reality you can use Io functions in an NDIS driver b/c that
> is exactly what an NDIS-WDM driver is
>
>
>
> So, IMHO you can call IoGetDeviceProperty. It doesn’t have an NDIS
> equivalent AFAIK, it does not change state and there are WDK NDIS samples
> which make this call (see src\kmdf\ndisedge\60, ndiswdm.c).
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of amitr0
> Sent: Wednesday, July 11, 2007 4:35 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] pci function number and device number
>
>
>
> Well, one reason is I can get teh PDO, but even with the PDO, I will need
> to call IoGet functions to get eth data, but MS doesnt recommend calling
> Io functions in NDIS. So thought of doing a work around.
>
>
>
> amitr0
>
>
>
>
>
>
>
> On 7/12/07, Doron Holan wrote:
>
> You need the PDO. Why can’t you call NdisMGetDeviceProperty get the PDO ?
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Wednesday, July 11, 2007 3:18 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] pci function number and device number
>
>
>
> hi all,
>
>
>
> I am in an NDIS miniport functional driver. And I need to find out the pci
> function number and slot number from simply teh NDIS_HANDLE.
>
>
>
> I cannot call NdisMGetDeviceProperty to get eh PDO handle else i would
> have done it the usual way by calling IoGetDeviceProperty.
>
>
>
>
>
> Is there any other way, WITHOUT the PDO to find out this information in an
> NDIS miniport.
>
>
>
> Pease note that I am on Vista, and the solution does not require to be
> backward compatible.
>
>
>
>
>
> –
>
> - amitr0
>
> — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
>
> –
>
> - amitr0 — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
Doron,
* In reality you can use Io functions in an NDIS driver b/c that is exactly
what an NDIS-WDM driver is
I would advise a guy who wrote the above MSDN statement that you have quoted to try calling IoCreateDvice() in NDIS miniport driver, so that he has a chance to see what happens…
A call in itself will be successfull, but any subsequent IRP_MJ_CREATE request to the target device will be immediately followed by IRP_MJ_CLOSE one that is sent by NDIS wrapper, so that the target device will be, in practical terms, just unusable. Therefore, Ioxxx calls in NDIS drivers should be judged on case-by-case basis - if your Ioxxx call logically implies some subsequent actions and NDIS wrapper is able to monitor these actions, it may just screw up things for you if it feels like…
Anton Bassov
You are taking what I said way too literally. I was using “Io” as way
to talk about non NDIS exported functions. IoCreateDevice falls into
the state changing Io calls that you should not make. Let’s be more
clear here.
NDIS owns the top edge (incoming i/o) for the driver. You can’t futz
with that using WDM, you must use NDIS to configure your top edge. NDIS
also exposes functionality that allows you to control the bottom edge
(hw registers, dma, etc) of your driver. NDIS has no idea how your
hardware works, so while it provides the functionality to let you talk
to your device, NDIS does not own the lower edge. An NDIS-WDM driver is
a driver which uses WDM for its lower edge while still using NDIS to
completely control the upper edge. So that means that you can safely
use non state change Io APIs like IoGetDeviceProperty even in a full
NDIS driver because it is essentially a lower edge API.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, July 12, 2007 3:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] pci function number and device number
Doron,
* In reality you can use Io functions in an NDIS driver b/c
that is exactly
what an NDIS-WDM driver is
I would advise a guy who wrote the above MSDN statement that you have
quoted to try calling IoCreateDvice() in NDIS miniport driver, so that
he has a chance to see what happens…
A call in itself will be successfull, but any subsequent IRP_MJ_CREATE
request to the target device will be immediately followed by
IRP_MJ_CLOSE one that is sent by NDIS wrapper, so that the target device
will be, in practical terms, just unusable. Therefore, Ioxxx calls in
NDIS drivers should be judged on case-by-case basis - if your Ioxxx
call logically implies some subsequent actions and NDIS wrapper is able
to monitor these actions, it may just screw up things for you if it
feels like…
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
This brings up a point that has LONG been a thorn in the side of third party
driver developers. Namely, you guys do not explicitly state what is or what
is not allowed in these drivers for WHQL. The response I have gotten from
MSFT before is you are free to look through the HCT scripts and see what is
allowed for yourself. Well that is great after I have spent months in dev
and test getting a driver to do what I need just to find out that even
though my driver is working as designed and will never hurt a soul, MSFT
doesn’t like some choice I made because some others have made the same
choice and screwed things up. Now, I have to find a work around or worse go
convince my product management team that they really didn’t want feature XYZ
at the last minute.
I guess now with the ability to dynamically load any function I want, who
cares…but it seems MSFT might care. You guys should force some
documentation tasks on someone to let people know at design decision time
what they can and can’t do. Just my $0.02.
Bill M.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
You are taking what I said way too literally. I was using “Io” as way
to talk about non NDIS exported functions. IoCreateDevice falls into
the state changing Io calls that you should not make. Let’s be more
clear here.
NDIS owns the top edge (incoming i/o) for the driver. You can’t futz
with that using WDM, you must use NDIS to configure your top edge. NDIS
also exposes functionality that allows you to control the bottom edge
(hw registers, dma, etc) of your driver. NDIS has no idea how your
hardware works, so while it provides the functionality to let you talk
to your device, NDIS does not own the lower edge. An NDIS-WDM driver is
a driver which uses WDM for its lower edge while still using NDIS to
completely control the upper edge. So that means that you can safely
use non state change Io APIs like IoGetDeviceProperty even in a full
NDIS driver because it is essentially a lower edge API.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, July 12, 2007 3:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] pci function number and device number
Doron,
> * In reality you can use Io functions in an NDIS driver b/c
that is exactly
> what an NDIS-WDM driver is
I would advise a guy who wrote the above MSDN statement that you have
quoted to try calling IoCreateDvice() in NDIS miniport driver, so that
he has a chance to see what happens…
A call in itself will be successfull, but any subsequent IRP_MJ_CREATE
request to the target device will be immediately followed by
IRP_MJ_CLOSE one that is sent by NDIS wrapper, so that the target device
will be, in practical terms, just unusable. Therefore, Ioxxx calls in
NDIS drivers should be judged on case-by-case basis - if your Ioxxx
call logically implies some subsequent actions and NDIS wrapper is able
to monitor these actions, it may just screw up things for you if it
feels like…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Bill McKenzie wrote:
Well that is great after I have spent months in dev and test
getting a driver to do what I need just to find out that even
though my driver is working as designed and will never hurt
a soul, MSFT doesn’t like some choice I made because some
others have made the same choice and screwed things up.
This isn’t a new problem. For a good laugh, read this thread:
(or just Google for “lick output hole NDIS” :))
I guess now with the ability to dynamically load any function I want,
who cares…
Careful with MmGetSystemRoutineAddress()…
Doron,
you can safely use non state change Io APIs like IoGetDeviceProperty even in a full
NDIS driver because it is essentially a lower edge API.
At this point quite interesting question arises ,namely, what can and what cannot get done by a driver that requires certification. Let’s say you want to present some device as NIC, so that you write WDM driver X that actually controls underlying device, plus virtual miniport driver Y that deals with NDIS on its upper edge and with driver X on its lower one. Therefore, on its lower edge driver Y is nothing more than just WDM client, and, hence, should be able to call all functions that WDM drivers do, including Io,Ke,Ps,etc. Under which circumstances will MSFT refuse driver’s Y certification?
Anton Bassov
I don’t own nor am I familiar with the NDIS logo tests so I can’t give
you the exact conditions. Driver y as you described it is an NDIS-WDM
driver and I know this type of driver is logo-able. The combo of driver
x/y as you describe it is a WDK KMDF sample in the WDK as well.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, July 12, 2007 2:08 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] pci function number and device number
Doron,
you can safely use non state change Io APIs like IoGetDeviceProperty
even in a full
NDIS driver because it is essentially a lower edge API.
At this point quite interesting question arises ,namely, what can and
what cannot get done by a driver that requires certification. Let’s say
you want to present some device as NIC, so that you write WDM driver X
that actually controls underlying device, plus virtual miniport driver Y
that deals with NDIS on its upper edge and with driver X on its lower
one. Therefore, on its lower edge driver Y is nothing more than just WDM
client, and, hence, should be able to call all functions that WDM
drivers do, including Io,Ke,Ps,etc. Under which circumstances will MSFT
refuse driver’s Y certification?
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“Doron Holan” wrote in message
news:xxxxx@ntdev…
>> I don’t own nor am I familiar with the NDIS logo tests so I can’t give
>> you the exact conditions. Driver y as you described it is an NDIS-WDM
>> driver and I know this type of driver is logo-able. The combo of driver
>> x/y as you describe it is a WDK KMDF sample in the WDK as well.
The problem is you have to show justification on why you could not do a
pure NDIS mini-port and not use functions like that. From what I can tell
the descision is based on who you can have scream for you, and has nothing
technical or quality wise to do with it.
The worst driver I ever saw source for was an NDIS driver that violated the
rules and was a total hack (for instance they made their own include with
parts of NTDDK.H and parts of NDIS.H). It got a Datacenter Logo back when
there was that program because DELL needed it for their cluster
interconnect. Now Datacenter logo required running for weeks, but this
thing would leak memory that showed it could never have made it, but it had
the logo.
Of course that is before things got really crappy with DTM/WLK and the
constant churn. Gee you have to use DTM starting June 8, but only until
August 3 when you have to use WLK 1.0c, which should shortly be replacesd
with one for Longhorn.
Fortunately WHQL has nothing to do with driver quality or with adequate
testing of a driver or a device. Unfortunately, it wastes a lot of time
that could have been used to find bugs and improve reliability.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
> This isn’t a new problem. For a good laugh, read this thread:
I know…billy_driverhound was me, thus I speak from experience 
Careful with MmGetSystemRoutineAddress()…
Well yeah…it may bluescreen. I don’t use it anymore. AND, as I recall
the WHQL tests explicitly check for this import in NDIS drivers. Ah…but
there is always more than one way to skin a cat.
BTW, I don’t expect Doron to solve this problem, but who else do we talk to?
This has been a problem for years and yet it still exists.
Bill M.
wrote in message news:xxxxx@ntdev…
> Bill McKenzie wrote:
>
>> Well that is great after I have spent months in dev and test
>> getting a driver to do what I need just to find out that even
>> though my driver is working as designed and will never hurt
>> a soul, MSFT doesn’t like some choice I made because some
>> others have made the same choice and screwed things up.
>
> This isn’t a new problem. For a good laugh, read this thread:
>
> http://tinyurl.com/2jfzpb
>
> (or just Google for “lick output hole NDIS” :))
>
>> I guess now with the ability to dynamically load any function I want,
>> who cares…
>
> Careful with MmGetSystemRoutineAddress()…
>