Prev: How to show media/cable disconnected
Next: Printer Name Issue
From: Steve Dispensa on 24 Jul 2006 21:32
On 2006-07-24 18:19:37 -0500, chris.aseltine(a)gmail.com said:

> Steve Dispensa wrote:
>
>>> Also, if I
>>> were to look for this device with SetupDiEnumDeviceInterfaces(), which
>>> GUID would I use? I don't see a GUID argument to that call.
>>
>> It creates a named device object, so you just access it by name - no
>> need of using GUIDs or SetupDi* calls at all.
>
> Okay, (and I'm probably being obtuse here) -- so say I name it
> \Device\MyUsbDevice001, 002, 003, etc. (this driver definitely needs to
> support multiple devices being present on the system at once.)
>
> What mechanism would I use from userspace to determine which
> MyUsbDevice* named device objects are present on the system?
>
> Would I need to just start from 001 and probe with CreateFile until I
> get an invalid handle as my return value?

One way would be to make one control device suffice for all virtual
adapters. Another would be to export a master control device
(\Device\MyUsbDevice) that you can attach to and query for the number
and names of the supported devices.

-sd

From: Eliyas Yakub [MSFT] on 24 Jul 2006 21:35
NDIS registers GUID_NDIS_LAN_CLASS for the devices it creates. So you can
find the instances by using SetupDiEnumDeviceInterfaces.

The device (aka control-device) you register using NdisMRegisterDevice is
not a PNP device. So you can't use SetupDi functions to find them.
Typcially, you just create one global control-device for all instances of
your physical device and devise a scheme to identify a particular instance
when you are sending ioctl from usermode.

Hint: Usermode app can identify a particular instance by enumerating the
interfaces registered by NDIS and from there find more information about the
device using SetupDiGetDeviceRegistryProperty. Given the PDO of the device,
the driver can do the same using IoGetDeviceProperty. So they both have some
common cookie to match up.


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/tips/default.mspx


From: Doron Holan [MS] on 24 Jul 2006 23:11
i am in the middle of this, but if you are naming each NIC with these names,
don't. just use device interfaces and let the system create the name for
you. device interfaces are enumerable and discoverable. what if there is a
hole in your naming b/c of plug/unplug?

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<chris.aseltine(a)gmail.com> wrote in message
news:1153783177.311532.80800(a)75g2000cwc.googlegroups.com...
> Steve Dispensa wrote:
>
>> > Also, if I
>> > were to look for this device with SetupDiEnumDeviceInterfaces(), which
>> > GUID would I use? I don't see a GUID argument to that call.
>>
>> It creates a named device object, so you just access it by name - no
>> need of using GUIDs or SetupDi* calls at all.
>
> Okay, (and I'm probably being obtuse here) -- so say I name it
> \Device\MyUsbDevice001, 002, 003, etc. (this driver definitely needs to
> support multiple devices being present on the system at once.)
>
> What mechanism would I use from userspace to determine which
> MyUsbDevice* named device objects are present on the system?
>
> Would I need to just start from 001 and probe with CreateFile until I
> get an invalid handle as my return value?
>


From: chris.aseltine on 25 Jul 2006 00:22
Folks,

My apologies, but at this point I have to admit I am getting fairly
confused.

Eliyas, you wrote:

> NDIS registers GUID_NDIS_LAN_CLASS for the devices it creates. So you can
> find the instances by using SetupDiEnumDeviceInterfaces.
>
> The device (aka control-device) you register using NdisMRegisterDevice is
> not a PNP device. So you can't use SetupDi functions to find them.

I'm assuming here that you mean you can find the "network card"
interfaces, but not the "device control" interfaces, using SetupDi().

> Typcially, you just create one global control-device for all instances of
> your physical device and devise a scheme to identify a particular instance
> when you are sending ioctl from usermode.

I did look in regedit and can see all the instances of
GUID_NDIS_LAN_CLASS, but all that's there is the SymbolicLink and
DeviceInstance. It's not clear to me how to get the filename /
symbolic link for my "control device" from either of those.

> Hint: Usermode app can identify a particular instance by enumerating the
> interfaces registered by NDIS and from there find more information about the
> device using SetupDiGetDeviceRegistryProperty. Given the PDO of the device,
> the driver can do the same using IoGetDeviceProperty. So they both have some
> common cookie to match up.

Whoa -- I've never used SetupDiGetDeviceRegistryProperty() inside
SetupDiEnumDeviceInterfaces() -- only SetupDiEnumDeviceInfo(). Are you
saying to query for, say, SPDRP_PHYSICAL_DEVICE_OBJECT_NAME? And then,
....???

I can see from the MSDN page on IoGetDeviceProperty that both the
driver and usermode app could know the PDO, but I don't see how to go
from there to the symbolic link / file path to the "control device".

Now, Doron, you wrote:

> i am in the middle of this, but if you are naming each NIC with these names,
> don't. just use device interfaces and let the system create the name for
> you. device interfaces are enumerable and discoverable. what if there is a
> hole in your naming b/c of plug/unplug?

I totally get what you are saying about the hole in naming because of
plug/unplug -- clearly that wouldn't work.

However, I'm not sure what you mean about "just [using] device
interfaces [which] are enumerable and discoverable", in light of
Eliyas' comment that the "control devices" are not as such, and I don't
see right now how to find the "control device" from the
GUID_NDIS_LAN_CLASS device which can be found.

I don't think you meant that I should register my own device interface,
because as far as I understand, I absolutely am not allowed to do that
from within an NDIS miniport.

Thanks and sorry for the confusion...!

-Chris

From: Eliyas Yakub [MSFT] on 25 Jul 2006 17:04
Let me repeat again.

1) For every instance of your miniport, NDIS registers an interface. This is
discoverable and openable from usermode but you cannot send ioctl to it.

2) So, you are asked to create a named control-device using
NdisMRegisterDevice. Here, you have the option of just creating one
control-device for all instances of miniport (just like the way NETVMINI
sample does) or create one per instance.

3) There is no API to discover control-devices in your mode. You just have
to know the symbolic name to open it.

4) If you just create one control-device, you don't have to worry about the
discovery issue. You know the hardcoded symbolic name so you can just open
that.

So the question is how do I identify a particular instance when I talk to
the driver using one control-device.

For that, you use the NDIS registered interface guid to enumerate the
device, identify the device you want to target, get some unique information
about the device (pdo-name, etc) and send that information (cookie) in the
ioctl.

In your driver, as the miniport instances are added, you find the same
unique information about the device in your MiniportInitializeHandler using
IoGetDeviceProperty and keep it in the miniport-context. You have to have a
global structure that contains a link to all the miniport contexts.

In your ioctl, walk the miniport context list (protected by a spinlock),
looking for a matching device based on the cookie. Problem solved.


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/tips/default.mspx


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How to show media/cable disconnected
Next: Printer Name Issue