It is possible to load a driver from another.
-Will it disrrupt Win2000 (or XP) activity if a driver ( a scsi driver)
will load the complete tcp stack ( e1000, Ndis.sys , tcp.sys ,
tdi.sys …) from its driver entry routine i.e. when it comes to the
tcp stack to be loaded according to the registry , the kernel will avoid
loading them because they ar e already loaded ?
-Is the above list of tcp stack drivers complete ?
-Is there some more activity / registration that has to be done in order
to perform the early tcp stack loading correctly ?
At a minimum you will flunk driver whql testing as your scsiminiport driver
will be using the wrong apis.
=====================
Mark Roddy
-----Original Message-----
From: Zvi Dubitzki [mailto:dubi@il.ibm.com]
Sent: Monday, November 24, 2003 1:01 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] load tcp stack earlierIt is possible to load a driver from another.
-Will it disrrupt Win2000 (or XP) activity if a driver ( a
scsi driver) will load the complete tcp stack ( e1000,
Ndis.sys , tcp.sys , tdi.sys …) from its driver entry
routine i.e. when it comes to the tcp stack to be loaded
according to the registry , the kernel will avoid loading
them because they ar e already loaded ?
-Is the above list of tcp stack drivers complete ?
-Is there some more activity / registration that has to be
done in order to perform the early tcp stack loading correctly ?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
On Mon, 2003-11-24 at 00:01, Zvi Dubitzki wrote:
It is possible to load a driver from another.
-Will it disrrupt Win2000 (or XP) activity if a driver ( a scsi driver)
will load the complete tcp stack ( e1000, Ndis.sys , tcp.sys ,
tdi.sys …) from its driver entry routine i.e. when it comes to the
tcp stack to be loaded according to the registry , the kernel will avoid
loading them because they ar e already loaded ?
-Is the above list of tcp stack drivers complete ?
-Is there some more activity / registration that has to be done in order
to perform the early tcp stack loading correctly ?
You could probably test all of this by messing around with the Start
values and load groups in the registry. Doesn’t sound like it’s likely
to pass whql though.
As to the completeness of the list, it depends on how you’re using the
various parts of the networking stack. Also, IM drivers will have to
get loaded in that list, if there are any. AFAIK, every NIC that starts
causes NDIS to load any protocols that could bind to it, and the
protocol edge of the IM drivers starts its miniport edge, which triggers
eventual loading of the rest of the protocols (or IMs). I don’t know
when protocols are loaded, though - NDIS might wait until too late for
you in the boot process to bring the protocols up, in which case you’ll
have to do some very clever processing of the bindings info in the
registry and replicate the load process yourself.
There’s probably a better way to do this - read up on NDIS_WDM - but I’m
curious to know what your application is. This sounds interesting,
complicated, and… inadvisable. 
That said, I’m curious to know what
you come up with.
-sd
The Start and Load groups do not work when it comes to the TCP stack. As I
understand it the TCP stack is still NT version and is not PnP aware, thus
the load order grouping does not work.
A solution we arrived at with MS support direction is to spawn a workitem
which sleeps for awhile, tries to establish the TCP connection, and then
either goes back to sleep again or completes depending upon whether the
connection is made or not. This allows the protocol to properly start on
it’s own and insures that it is completely up rather than attempting to
start it on your own and pray that everything was started and in the proper
order.
“Steve Dispensa” wrote in message
news:xxxxx@ntdev…
>
> On Mon, 2003-11-24 at 00:01, Zvi Dubitzki wrote:
> > It is possible to load a driver from another.
> > -Will it disrrupt Win2000 (or XP) activity if a driver ( a scsi driver)
> > will load the complete tcp stack ( e1000, Ndis.sys , tcp.sys ,
> > tdi.sys …) from its driver entry routine i.e. when it comes to the
> > tcp stack to be loaded according to the registry , the kernel will
avoid
> > loading them because they ar e already loaded ?
> > -Is the above list of tcp stack drivers complete ?
> > -Is there some more activity / registration that has to be done in order
> > to perform the early tcp stack loading correctly ?
>
> You could probably test all of this by messing around with the Start
> values and load groups in the registry. Doesn’t sound like it’s likely
> to pass whql though.
>
> As to the completeness of the list, it depends on how you’re using the
> various parts of the networking stack. Also, IM drivers will have to
> get loaded in that list, if there are any. AFAIK, every NIC that starts
> causes NDIS to load any protocols that could bind to it, and the
> protocol edge of the IM drivers starts its miniport edge, which triggers
> eventual loading of the rest of the protocols (or IMs). I don’t know
> when protocols are loaded, though - NDIS might wait until too late for
> you in the boot process to bring the protocols up, in which case you’ll
> have to do some very clever processing of the bindings info in the
> registry and replicate the load process yourself.
>
> There’s probably a better way to do this - read up on NDIS_WDM - but I’m
> curious to know what your application is. This sounds interesting,
> complicated, and… inadvisable. That said, I’m curious to know what
> you come up with.
>
> -sd
>
>
>
>
On Tue, 2003-11-25 at 12:38, Del Fredricks wrote:
The Start and Load groups do not work when it comes to the TCP stack. As I
understand it the TCP stack is still NT version and is not PnP aware, thus
the load order grouping does not work.
The tcpip.sys from windows 2000 is PnP-aware. It registers as an NDIS4
protocol and exports handlers for BindAdapter, UnbindAdapter, and
TranslateAdapter.
Also, what’s being PnP-aware have to do with this? I thought the IO
manager decided when to load drivers.
Anyway, I’ve never tried any of this; I could be way off. I just find
it interesting.
-sd
“Steve Dispensa” wrote in message
news:xxxxx@ntdev…
>
> On Tue, 2003-11-25 at 12:38, Del Fredricks wrote:
> > The Start and Load groups do not work when it comes to the TCP stack.
As I
> > understand it the TCP stack is still NT version and is not PnP aware,
thus
> > the load order grouping does not work.
>
> The tcpip.sys from windows 2000 is PnP-aware. It registers as an NDIS4
> protocol and exports handlers for BindAdapter, UnbindAdapter, and
> TranslateAdapter.
>
If I am not mistaken, these are NDIS callback functions, not PnP.
>
> Also, what’s being PnP-aware have to do with this? I thought the IO
> manager decided when to load drivers.
>
As I understood it when I first encountered this problem with our serial
over IP devices, TCP does not report itself to PnP. Thus, the
LoadOrderGroup or Dependencies entries of a Service-Install section of an
INF are meaningless. I was informed that the TCP protocol in Windows 2000,
and carried forward for XP, is the same one brought forward from NT and had
not been modified for full PnP interaction.
While the IO Manager may decide when to load a driver, although this too is
somewhat controled by the StartType entry in the same Service-Install
section of the INF, it must first get a list of which devices are in the
system from PnP so that it knows which drivers need to be loaded.
>
> Anyway, I’ve never tried any of this; I could be way off. I just find
> it interesting.
>
It was also a bit challenging when I had to tackle it was well.
BTW, I should also mention that if the driver source needs to support NT
devices as well as 2000/XP/2003, then one has to use system threads instead
of workitems as the latter did not exist in NT.
> and carried forward for XP, is the same one brought forward from NT and had
not been modified for full PnP interaction.
TdiRegisterPnPHandlers is the TCP’s way of interacting with PnP.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
TdiRegisterPnPHandlers can work.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Del Fredricks”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, November 25, 2003 9:38 PM
Subject: [ntdev] Re: load tcp stack earlier
> The Start and Load groups do not work when it comes to the TCP stack. As I
> understand it the TCP stack is still NT version and is not PnP aware, thus
> the load order grouping does not work.
>
> A solution we arrived at with MS support direction is to spawn a workitem
> which sleeps for awhile, tries to establish the TCP connection, and then
> either goes back to sleep again or completes depending upon whether the
> connection is made or not. This allows the protocol to properly start on
> it’s own and insures that it is completely up rather than attempting to
> start it on your own and pray that everything was started and in the proper
> order.
>
> “Steve Dispensa” wrote in message
> news:xxxxx@ntdev…
> >
> > On Mon, 2003-11-24 at 00:01, Zvi Dubitzki wrote:
> > > It is possible to load a driver from another.
> > > -Will it disrrupt Win2000 (or XP) activity if a driver ( a scsi driver)
> > > will load the complete tcp stack ( e1000, Ndis.sys , tcp.sys ,
> > > tdi.sys …) from its driver entry routine i.e. when it comes to the
> > > tcp stack to be loaded according to the registry , the kernel will
> avoid
> > > loading them because they ar e already loaded ?
> > > -Is the above list of tcp stack drivers complete ?
> > > -Is there some more activity / registration that has to be done in order
> > > to perform the early tcp stack loading correctly ?
> >
> > You could probably test all of this by messing around with the Start
> > values and load groups in the registry. Doesn’t sound like it’s likely
> > to pass whql though.
> >
> > As to the completeness of the list, it depends on how you’re using the
> > various parts of the networking stack. Also, IM drivers will have to
> > get loaded in that list, if there are any. AFAIK, every NIC that starts
> > causes NDIS to load any protocols that could bind to it, and the
> > protocol edge of the IM drivers starts its miniport edge, which triggers
> > eventual loading of the rest of the protocols (or IMs). I don’t know
> > when protocols are loaded, though - NDIS might wait until too late for
> > you in the boot process to bring the protocols up, in which case you’ll
> > have to do some very clever processing of the bindings info in the
> > registry and replicate the load process yourself.
> >
> > There’s probably a better way to do this - read up on NDIS_WDM - but I’m
> > curious to know what your application is. This sounds interesting,
> > complicated, and… inadvisable. That said, I’m curious to know what
> > you come up with.
> >
> > -sd
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com