|
Message 3 of 3
03 Jan 01 14:17
|
|
xxxxxx@microsoft.com
|
Join Date:
Posts To This List: 222
|
|
|
RE: NdisIMInitializeDeviceInstanceEx
<![CDATA[The purpose and use of this parameter can be understood by going through the
Passthru sample. The description of this function in the DDK doc only
applies to filter IM driver. The doc doesn't really say who creates this
string, why it creates it and how NDIS gets it. This information is very
important to know if you want to write Mux IM. I'm going to take this
opportunity to explain the working of MUX IM driver. So hold your head...
If you check the PtBindAdapter handler in Passthru, it gets the
DriverInstance parameter from the registry by reading the "UpperBindings"
value. The bind engine (net class installer) during install creates the
virtual NIC instance for every real adapter and stores a GUID that
represents the instance in the registry. The virtual NIC instance so far is
just a usermode representation. It gets life and gets initialized only when
the driver calls NdisIMInitializeDeviceInstanceEx.
For filter IM, you are expected to call this immediately after you bind to
real NIC. This ensures one to one mapping and that's how the IM driver
becomes a filter.
For MUX IM, an IM driver that is designed to have multiple virtual miniports
associated with one real device miniport, you must write a notify object
that does fundamentally two things. It has to add and remove virtual
miniports at appropriate times, i.e., install, reconfigure, uninstall. It
has to maintain in the transport service - MUX IM drivers are installed as
NetTrans instead of NetService - registry parameter settings the names of
the devices that correspond to the virtual miniports. A perfect example is
the ATM LANE driver.
Here's how ATM LANE's notify object keeps track of things in the registry:
Under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services:
AtmLane
Enum
Linkage
Parameters
Adapters
{GUID1 representing first ATM adapter}
ElanList
{GUID2 representing an ELAN which is a virtual miniport
device}
Device:REG_SZ:\Device\{GUID2 for virtual miniport
device}
{GUID3 represnting a second ELAN which is a virtual
miniport device}
Device:REG_SZ:\Device\{GUID3 for virtual miniport
device}
So for each real ATM adapter that the ATM LANE driver is bound to there is a
corresponding GUID key under the Adapters key. Under that key is a key
ElanList. Under that key is a list of virtual miniports that represent an
Emulated LAN. Under each of those is a "Device" that is the name of the
device to pass to NdisImInitializeDeviceInstanceEx. Everything in the
registry from ElanList below is managed by the notify object. The driver
upon starting goes thru the ElanList and starts the miniport devices it
finds there. If there is a second ATM adapter in the machine there would be
another key with a GUID under Adapters for the second ATM adapter and it
would have it's own ElanList. Again the ElanList key and things below it
are structured to work only with the LANE notify object. A developer could
use their own scheme.
NOTES:
For filter IM's this scheme is fixed ("UpperBindings") and provided by the
system for you. The NetClass installer does almost all the work of creating
and deleting the virtual intance. That's where the FilterClass you specify
in the INF file comes into picture. It tells the class installer what kind
of filter IM you are. Note this filter class in not used for MUX IM.
The "UpperBindings" - plural - is a misnomer. It is a REG_SZ string - not
REG_MULTI_SZ. By definition this parameter will never have more than one
device name in it as the Network Class installer won't put more than one
there.
The ATM LANE does not call NdisIMInitializeDeviceInstance in it's
ProtocolBindAdapter. It initializes/De-initializes later in an NDIS work
item thread whenever the Notify object DLL prompts it.
This whole stuff is complex. You should go through the LANE INF files and
try out to understand this little better. We are working on a generic MUX
sample, and our work for some reason is going at a very slow pace. We have
completed some pieces but not good enough to give out to public. All the
interfaces you need are documented. You just have to work hard to put them
together.
I hope we come up with some amount of system support to simplify MUX IM
driver development.
-Eliyas
-----Original Message-----
From: Vodicka, Michal [mailto:xxxxx@rkk.cz]
Sent: Wednesday, January 03, 2001 9:28 AM
To: NT Developers Interest List
Subject: [ntdev] RE: NdisIMInitializeDeviceInstanceEx
It is for NDIS use. Every adapter is internally represented as a device and
this is device name. NDIS probably uses it also for other things;
disassemble ndis.sys if you want to know details.
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
> ----------
> From: Matteo Pelati[SMTP:xxxxx@dolce.it]
> Reply To: NT Developers Interest List
> Sent: Wednesday, January 03, 2001 2:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] NdisIMInitializeDeviceInstanceEx
>
<...excess quoted lines suppressed...>
---
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to
leave-ntdev-$subst('Recip.MemberIDChar')@lists.osr.com
---
You are currently subscribed to ntdev as: $subst('Recip.EmailAddr')
To unsubscribe send a blank email to
leave-ntdev-$subst('Recip.MemberIDChar')@lists.osr.com
]]>
|
NdisIMInitializeDeviceInstanceEx