Driver starting another.

Hi all,

I am looking for ways to start a second driver from a driver.

Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).

Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.

Thanks, Chris

> Hi all,

I am looking for ways to start a second driver from a driver.

Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).

Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.

Thanks, Chris

Except for the loading of the driver we just did this at my firm. You
might
want to consider using an interface and having the Foo bus call
IoRegisterPlugPlayNotification to be notified of device activation and
removal.

Don Burn
Egenera, Inc

Thanks, I like that idea very much.

wrote in message news:xxxxx@ntdev…
>
> > Hi all,
> >
> > I am looking for ways to start a second driver from a driver.
> >
> > Here’s the situation:
> > In response to the PNP manager loading the driver for my device I want
to
> > spawn a new bus (call it Foo) that is not attached to the same stack
as my
> > device (it can’t be related to the device’s driver). Once the Foo bus
is
> > running, the device driver needs to be able to unload and reload without
> > disturbing the Foo bus and it’s children. When the device driver is
going
> > to unload, it will send notification to the Foo bus (probably via an
IOCTL).
> > When the device driver comes back it needs to be able to find the Foo
bus
> > (if it exists) and then send another IOCTL notifying the Foo bus that it
is
> > present (if the Foo bus cannot be found then it would create it, just as
it
> > did on initial startup).
> >
> > Is this possible to do?
> > If yes, then how should I approach the task of creating the Foo bus? I
hope
> > that the Foo bus can be created and run just like a regular PNP bus
driver.
> >
> > Thanks, Chris
>
> Except for the loading of the driver we just did this at my firm. You
> might
> want to consider using an interface and having the Foo bus call
> IoRegisterPlugPlayNotification to be notified of device activation and
> removal.
>
> Don Burn
> Egenera, Inc
>
>

If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a “open
source” ntifs.h by search google. Copy the prototype, you should have no
problem linking because this function is exported.

Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,

I am looking for ways to start a second driver from a driver.

Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).

Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.

Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

ZwLoadDriver()
ZwUnloadDrvier()

Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Dor?
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,

I am looking for ways to start a second driver from a driver.

Here’s the situation:
In response to the PNP manager loading the driver for my device I want
to
spawn a new bus (call it Foo) that is not attached to the same stack
as my
device (it can’t be related to the device’s driver). Once the Foo bus
is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is
going
to unload, it will send notification to the Foo bus (probably via an
IOCTL).
When the device driver comes back it needs to be able to find the Foo
bus
(if it exists) and then send another IOCTL notifying the Foo bus that it
is
present (if the Foo bus cannot be found then it would create it, just as
it
did on initial startup).

Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I
hope
that the Foo bus can be created and run just like a regular PNP bus
driver.

Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

RE: [ntdev] Driver starting another.From what I’ve been reading about
ZwLoadDriver, it is only good for loading legacy drivers and will only cause
DriverEntry to be called. I am looking for a solution that will start a
complete PNP/WDM driver. Toaster does not help all that much because that
bus driver is installed in response to the user adding it from “Add
Hardware”.

It’s too bad I can’t create a PDO on root, or somewhere floating in space,
and then report it as being a new device to find a driver for…or can I
somehow?

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…
If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a “open
source” ntifs.h by search google. Copy the prototype, you should have no
problem linking because this function is exported.
Bi
-----Original Message-----
From: Chris Doré [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,
I am looking for ways to start a second driver from a driver.
Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).
Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.
Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

How does this sound?

If I install the Foo bus from a co-installer for my device and then have the
Foo service running at all times, my device driver could connect up to it
whenever it needs to. This way I can get the Foo bus installed easily the
first time my device is installed. Foo could simply register for PNP
notification as suggested in an earlier reply. In this case I believe
things would operate very much the same ay as the toaster bus (in terms of
receiving full PNP IRPs, etc.).

Chris

“Chris Doré” wrote in message news:xxxxx@ntdev…
>
> Thanks, I like that idea very much.
>
> wrote in message news:xxxxx@ntdev…
> >
> > > Hi all,
> > >
> > > I am looking for ways to start a second driver from a driver.
> > >
> > > Here’s the situation:
> > > In response to the PNP manager loading the driver for my device I want
> to
> > > spawn a new bus (call it Foo) that is not attached to the same stack
> as my
> > > device (it can’t be related to the device’s driver). Once the Foo bus
> is
> > > running, the device driver needs to be able to unload and reload
without
> > > disturbing the Foo bus and it’s children. When the device driver is
> going
> > > to unload, it will send notification to the Foo bus (probably via an
> IOCTL).
> > > When the device driver comes back it needs to be able to find the Foo
> bus
> > > (if it exists) and then send another IOCTL notifying the Foo bus that
it
> is
> > > present (if the Foo bus cannot be found then it would create it, just
as
> it
> > > did on initial startup).
> > >
> > > Is this possible to do?
> > > If yes, then how should I approach the task of creating the Foo bus? I
> hope
> > > that the Foo bus can be created and run just like a regular PNP bus
> driver.
> > >
> > > Thanks, Chris
> >
> > Except for the loading of the driver we just did this at my firm. You
> > might
> > want to consider using an interface and having the Foo bus call
> > IoRegisterPlugPlayNotification to be notified of device activation and
> > removal.
> >
> > Don Burn
> > Egenera, Inc
> >
> >
>
>
>
>

What you need is nothing like bus driver because you do not have a physical
PnP device and to do that in the toaster way is way to complicated for you

What you need is also not using load driver.

All you need is to create second device object in you AddDevice call. You
can either enable it will a different interface (with differnt GUID than you
main device) the WDM way or create a symbolic link the NT way. I don’t see
why the device cannot be related to your driver object since all your driver
object do is to dispatch IRP to your device. Obviously the extra device
object you create is not logical representation of physical device, you
don’t need a PDO for your FDO. You can delete this device object anytime you
want.

Note that bus driver create pdo responding to an external event, such as a
real signal invoked by external activity outside Northbridge that will
leads to physical bus re-enumeration. Toaster is a virtual bus that cannot
initiate a signal by itself, therefore it needs external user input.

Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 2:04 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

RE: [ntdev] Driver starting another.From what I’ve been reading about
ZwLoadDriver, it is only good for loading legacy drivers and will only cause
DriverEntry to be called. I am looking for a solution that will start a
complete PNP/WDM driver. Toaster does not help all that much because that
bus driver is installed in response to the user adding it from “Add
Hardware”.

It’s too bad I can’t create a PDO on root, or somewhere floating in space,
and then report it as being a new device to find a driver for…or can I
somehow?

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…
If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a “open
source” ntifs.h by search google. Copy the prototype, you should have no
problem linking because this function is exported.
Bi
-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,
I am looking for ways to start a second driver from a driver.
Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).
Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.
Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

RE: [ntdev] Re: Driver starting another.Creating multiple FDO’s from
AddDevice associates them with the DriverObject (that linked list at
DriverObject.DeviceObject), thus I don’t think the driver will be able to
unload properly while leaving one of the FDO’s behind. Or am I wrong, is
there a way to do this?

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…

What you need is nothing like bus driver because you do not have a physical
PnP device and to do that in the toaster way is way to complicated for you
What you need is also not using load driver.
All you need is to create second device object in you AddDevice call. You
can either enable it will a different interface (with differnt GUID than you
main device) the WDM way or create a symbolic link the NT way. I don’t see
why the device cannot be related to your driver object since all your driver
object do is to dispatch IRP to your device. Obviously the extra device
object you create is not logical representation of physical device, you
don’t need a PDO for your FDO. You can delete this device object anytime you
want.
Note that bus driver create pdo responding to an external event, such as a
real signal invoked by external activity outside Northbridge that will
leads to physical bus re-enumeration. Toaster is a virtual bus that cannot
initiate a signal by itself, therefore it needs external user input.
Bi

-----Original Message-----
From: Chris Doré [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 2:04 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

RE: [ntdev] Driver starting another.From what I’ve been reading about
ZwLoadDriver, it is only good for loading legacy drivers and will only cause
DriverEntry to be called. I am looking for a solution that will start a
complete PNP/WDM driver. Toaster does not help all that much because that
bus driver is installed in response to the user adding it from “Add
Hardware”.
It’s too bad I can’t create a PDO on root, or somewhere floating in space,
and then report it as being a new device to find a driver for…or can I
somehow?
Thanks, Chris
“Bi Chen” wrote in message news:xxxxx@ntdev…
If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a “open
source” ntifs.h by search google. Copy the prototype, you should have no
problem linking because this function is exported.
Bi
-----Original Message-----
From: Chris Doré [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,
I am looking for ways to start a second driver from a driver.
Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).
Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.
Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

IoReportDetectedDevice. The documentation is confusing, but if I understand
the problem, this ought to allow you to create the unrelated PDO in either
DriverEntry or AddDevice *the first time your driver is loaded*. Note that
on subsequent reboots the PDO created will be a ‘root enumerated pdo’. Your
driver could be the function driver for this PDO or not, depending on your
design.

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Monday, September 09, 2002 10:08 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

RE: [ntdev] Re: Driver starting another.Creating multiple
FDO’s from AddDevice associates them with the DriverObject
(that linked list at DriverObject.DeviceObject), thus I don’t
think the driver will be able to unload properly while
leaving one of the FDO’s behind. Or am I wrong, is there a
way to do this?

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…
>
>
> What you need is nothing like bus driver because you do not
> have a physical PnP device and to do that in the toaster way
> is way to complicated for you What you need is also not using
> load driver. All you need is to create second device object
> in you AddDevice call. You can either enable it will a
> different interface (with differnt GUID than you main device)
> the WDM way or create a symbolic link the NT way. I don’t see
> why the device cannot be related to your driver object since
> all your driver object do is to dispatch IRP to your device.
> Obviously the extra device object you create is not logical
> representation of physical device, you don’t need a PDO for
> your FDO. You can delete this device object anytime you want.
> Note that bus driver create pdo responding to an external
> event, such as a real signal invoked by external activity
> outside Northbridge that will leads to physical bus
> re-enumeration. Toaster is a virtual bus that cannot initiate
> a signal by itself, therefore it needs external user input. Bi
>
>
> -----Original Message-----
> From: Chris Dor? [mailto:xxxxx@connecttech.com]
> Sent: Friday, September 06, 2002 2:04 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Driver starting another.
>
>
> RE: [ntdev] Driver starting another.From what I’ve been
> reading about ZwLoadDriver, it is only good for loading
> legacy drivers and will only cause DriverEntry to be called.
> I am looking for a solution that will start a complete
> PNP/WDM driver. Toaster does not help all that much because
> that bus driver is installed in response to the user adding
> it from “Add Hardware”. It’s too bad I can’t create a PDO on
> root, or somewhere floating in space, and then report it as
> being a new device to find a driver for…or can I somehow?
> Thanks, Chris “Bi Chen” wrote in
> message news:xxxxx@ntdev… If you have ifs kit, using
> ZwLoadDriver. If you don’t, you can find a “open source”
> ntifs.h by search google. Copy the prototype, you should have
> no problem linking because this function is exported. Bi
> -----Original Message-----
> From: Chris Dor? [mailto:xxxxx@connecttech.com]
> Sent: Friday, September 06, 2002 11:19 AM
> To: NT Developers Interest List
> Subject: [ntdev] Driver starting another.
>
>
> Hi all,
> I am looking for ways to start a second driver from a driver.
> Here’s the situation: In response to the PNP manager loading
> the driver for my device I want to spawn a new bus (call it
> Foo) that is not attached to the same stack as my device
> (it can’t be related to the device’s driver). Once the Foo
> bus is running, the device driver needs to be able to unload
> and reload without disturbing the Foo bus and it’s children.
> When the device driver is going to unload, it will send
> notification to the Foo bus (probably via an IOCTL). When the
> device driver comes back it needs to be able to find the Foo
> bus (if it exists) and then send another IOCTL notifying the
> Foo bus that it is present (if the Foo bus cannot be found
> then it would create it, just as it did on initial startup).
> Is this possible to do? If yes, then how should I approach
> the task of creating the Foo bus? I hope that the Foo bus can
> be created and run just like a regular PNP bus driver. Thanks, Chris
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>

Chris:

You have to ask yourself if your other device object’s life span is related
to your main device object or not, say it cannot exist if the main device
object does not exist. If that is the case, this means the other device
object is sort of slave device object to your main device object and all
device object reference counting goes to the main device object. Otherwise,
they are independent and you can use ZwLoadDriver.

Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Monday, September 09, 2002 7:08 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

RE: [ntdev] Re: Driver starting another.Creating multiple FDO’s from
AddDevice associates them with the DriverObject (that linked list at
DriverObject.DeviceObject), thus I don’t think the driver will be able to
unload properly while leaving one of the FDO’s behind. Or am I wrong, is
there a way to do this?

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…

What you need is nothing like bus driver because you do not have a physical
PnP device and to do that in the toaster way is way to complicated for you
What you need is also not using load driver.
All you need is to create second device object in you AddDevice call. You
can either enable it will a different interface (with differnt GUID than you
main device) the WDM way or create a symbolic link the NT way. I don’t see
why the device cannot be related to your driver object since all your driver
object do is to dispatch IRP to your device. Obviously the extra device
object you create is not logical representation of physical device, you
don’t need a PDO for your FDO. You can delete this device object anytime you
want.
Note that bus driver create pdo responding to an external event, such as a
real signal invoked by external activity outside Northbridge that will
leads to physical bus re-enumeration. Toaster is a virtual bus that cannot
initiate a signal by itself, therefore it needs external user input.
Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 2:04 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

RE: [ntdev] Driver starting another.From what I’ve been reading about
ZwLoadDriver, it is only good for loading legacy drivers and will only cause
DriverEntry to be called. I am looking for a solution that will start a
complete PNP/WDM driver. Toaster does not help all that much because that
bus driver is installed in response to the user adding it from “Add
Hardware”.
It’s too bad I can’t create a PDO on root, or somewhere floating in space,
and then report it as being a new device to find a driver for…or can I
somehow?
Thanks, Chris
“Bi Chen” wrote in message news:xxxxx@ntdev…
If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a “open
source” ntifs.h by search google. Copy the prototype, you should have no
problem linking because this function is exported.
Bi
-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Friday, September 06, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Driver starting another.

Hi all,
I am looking for ways to start a second driver from a driver.
Here’s the situation:
In response to the PNP manager loading the driver for my device I want to
spawn a new bus (call it Foo) that is not attached to the same stack as my
device (it can’t be related to the device’s driver). Once the Foo bus is
running, the device driver needs to be able to unload and reload without
disturbing the Foo bus and it’s children. When the device driver is going
to unload, it will send notification to the Foo bus (probably via an IOCTL).
When the device driver comes back it needs to be able to find the Foo bus
(if it exists) and then send another IOCTL notifying the Foo bus that it is
present (if the Foo bus cannot be found then it would create it, just as it
did on initial startup).
Is this possible to do?
If yes, then how should I approach the task of creating the Foo bus? I hope
that the Foo bus can be created and run just like a regular PNP bus driver.
Thanks, Chris


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

If I use ZwLoadDriver, can I do an InvaidateBusRelations and then create
children from the loaded driver that the PNP manager will then go out and
find drivers for? If so then this should work for me.

I am confused by what is meant by legacy driver. When people use the term
I’m not quite sure what they are referring to. I started device drivers
about a year ago and I’ve never done anything but WDM/PNP drivers.

Thanks, Chris

“Chris Doré” wrote in message news:xxxxx@ntdev…
>
> RE: [ntdev] Driver starting another.From what I’ve been reading about
> ZwLoadDriver, it is only good for loading legacy drivers and will only
cause
> DriverEntry to be called. I am looking for a solution that will start a
> complete PNP/WDM driver. Toaster does not help all that much because that
> bus driver is installed in response to the user adding it from “Add
> Hardware”.
>
> It’s too bad I can’t create a PDO on root, or somewhere floating in space,
> and then report it as being a new device to find a driver for…or can I
> somehow?
>
> Thanks, Chris
>
> “Bi Chen” wrote in message news:xxxxx@ntdev…
> If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a
“open
> source” ntifs.h by search google. Copy the prototype, you should have no
> problem linking because this function is exported.
> Bi
> -----Original Message-----
> From: Chris Doré [mailto:xxxxx@connecttech.com]
> Sent: Friday, September 06, 2002 11:19 AM
> To: NT Developers Interest List
> Subject: [ntdev] Driver starting another.
>
>
> Hi all,
> I am looking for ways to start a second driver from a driver.
> Here’s the situation:
> In response to the PNP manager loading the driver for my device I want to
> spawn a new bus (call it Foo) that is not attached to the same stack as
my
> device (it can’t be related to the device’s driver). Once the Foo bus is
> running, the device driver needs to be able to unload and reload without
> disturbing the Foo bus and it’s children. When the device driver is going
> to unload, it will send notification to the Foo bus (probably via an
IOCTL).
> When the device driver comes back it needs to be able to find the Foo bus
> (if it exists) and then send another IOCTL notifying the Foo bus that it
is
> present (if the Foo bus cannot be found then it would create it, just as
it
> did on initial startup).
> Is this possible to do?
> If yes, then how should I approach the task of creating the Foo bus? I
hope
> that the Foo bus can be created and run just like a regular PNP bus
driver.
> Thanks, Chris
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>

Hi, Chris:

I think you are bit confused with PnP and device node tree. If you can read
DDK PnP section, you will gain a lot of PnP understanding, especially if you
have not done any WDM/PnP driver.

A bus driver such as toaster can instantiate PDO based on the external
signal (fake bus driver such as toaster is response to external human
signal). It also reposible for turn on and off bus power supply (PCI 2.1,
2.2, USB, 1394) to specific device (slot, hub) connected on the bus. Bus
allows many devices connected to it to commuincate with host or each other.
Parallel bus uses out-of-band signal (extra wires) to arbitrate who can talk
to who or through positive decoding (don’t bother what it means if you don’t
know hardware well enough). Serial bus use framed message to do the same
(positive decoding). Does your hardware contain thing that can be called
bus? If it does not, don’t use bus driver to model your hardware.

Your hardware may be a multifunction device. Normally one need to implement
a driver for each functional device. Any Southbridge on your computer is
such a beast, So does digital still camera, just as an example. Anyway in
order to write driver for your hardware, you must first understand how to
use device node method to logically describe your driver.

A legacy device driver is NT 4.0 device driver that does not support
PnP/Power Management. For PCI like device, you have to enumerate devices on
the bus to see which one is yours. There are a lot of examples on how to do
that.

Good luck.

Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Tuesday, September 10, 2002 12:31 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

If I use ZwLoadDriver, can I do an InvaidateBusRelations and then create
children from the loaded driver that the PNP manager will then go out and
find drivers for? If so then this should work for me.

I am confused by what is meant by legacy driver. When people use the term
I’m not quite sure what they are referring to. I started device drivers
about a year ago and I’ve never done anything but WDM/PNP drivers.

Thanks, Chris

“Chris Dor?” wrote in message news:xxxxx@ntdev…
>
> RE: [ntdev] Driver starting another.From what I’ve been reading about
> ZwLoadDriver, it is only good for loading legacy drivers and will only
cause
> DriverEntry to be called. I am looking for a solution that will start a
> complete PNP/WDM driver. Toaster does not help all that much because that
> bus driver is installed in response to the user adding it from “Add
> Hardware”.
>
> It’s too bad I can’t create a PDO on root, or somewhere floating in space,
> and then report it as being a new device to find a driver for…or can I
> somehow?
>
> Thanks, Chris
>
> “Bi Chen” wrote in message news:xxxxx@ntdev…
> If you have ifs kit, using ZwLoadDriver. If you don’t, you can find a
“open
> source” ntifs.h by search google. Copy the prototype, you should have no
> problem linking because this function is exported.
> Bi
> -----Original Message-----
> From: Chris Dor? [mailto:xxxxx@connecttech.com]
> Sent: Friday, September 06, 2002 11:19 AM
> To: NT Developers Interest List
> Subject: [ntdev] Driver starting another.
>
>
> Hi all,
> I am looking for ways to start a second driver from a driver.
> Here’s the situation:
> In response to the PNP manager loading the driver for my device I want to
> spawn a new bus (call it Foo) that is not attached to the same stack as
my
> device (it can’t be related to the device’s driver). Once the Foo bus is
> running, the device driver needs to be able to unload and reload without
> disturbing the Foo bus and it’s children. When the device driver is going
> to unload, it will send notification to the Foo bus (probably via an
IOCTL).
> When the device driver comes back it needs to be able to find the Foo bus
> (if it exists) and then send another IOCTL notifying the Foo bus that it
is
> present (if the Foo bus cannot be found then it would create it, just as
it
> did on initial startup).
> Is this possible to do?
> If yes, then how should I approach the task of creating the Foo bus? I
hope
> that the Foo bus can be created and run just like a regular PNP bus
driver.
> Thanks, Chris
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

I will take another stab at explaining my situation with some more details
about what I want to do and my reasons.

My device hosts child devices, so that is why I am creating it as a bus
architecture.
Applications can open handles to the children to do reads/writes etc. (doing
so to the bus device makes no sense so I’ll ignore the possibility in this
explaination).

Now, normally I would just make the function driver of the bus device a bus
driver that creates the child PDO’s etc. This is what I had originally done.

Next came some problems when testing hibernation and standby. Because of
the way the hardware is designed, returning from hibernation causes the bus
device’s driver to be unloaded and reloaded (and all children of course).
This unload and reload cannot be stopped and for the purposes of my problem
should be treated as etched in stone. It’s like the device is surprise
removed from the system and then placed back in.

Now, when there are no handles open to the child devices everything goes
fine because the drivers can unload and reload without a problem. However,
if there are open handles, the drivers cannot unload properly and the device
cannot be restarted.

Here lies my reasons for wanting to move the bus to a root-enumerated-like
architecture. If the children are not on the same stack as the bus device,
then the bus device’s driver can unload and reload after a hibernation
without disturbing the children and their open handles.

I believe I came up with a solution today that would fix my problems but, as
always, alternate suggestions are welcome (why else would I be posting this
:).
From here on “Device” refers to the actual bus device that is plugged into
the system.
When the device is first plugged in, it’s driver co-installer first installs
the virtual bus (I could do this like you would if you installed the toaster
bus using devcon). Once the virtual bus is installed the system would
continue installing the device’s driver. This driver would proceed to start
the device and communicate to the virtual bus all the required information
about the children. The virtual bus would respond by creating the children
and reporting them after a call to IoInvalidateBusRelations.

When the system goes into hibernation the device’s driver signals the
virtual bus that it needs to treat the hardware as untouchable. The device’s
driver can unload and reload without a problem after returning from
hibernation. It can then “re-connect” to the virtual bus and get things
going again.

If you think about it, what I am trying to do is very similar to toaster
except that I need to control the virtual bus from a device driver instead
of a user mode app.

***Whatever solution I end up with must be signable.***

Thanks for everyone’s help in this matter, you have been giving me great
ideas to investigate.
Again, more ideas are very much welcome…I wouldn’t call myself an expert
on this stuff.
Chris


“Bi Chen” wrote in message news:xxxxx@ntdev…
Hi, Chris:

I think you are bit confused with PnP and device node tree. If you can read
DDK PnP section, you will gain a lot of PnP understanding, especially if you
have not done any WDM/PnP driver.

A bus driver such as toaster can instantiate PDO based on the external
signal (fake bus driver such as toaster is response to external human
signal). It also reposible for turn on and off bus power supply (PCI 2.1,
2.2, USB, 1394) to specific device (slot, hub) connected on the bus. Bus
allows many devices connected to it to commuincate with host or each other.
Parallel bus uses out-of-band signal (extra wires) to arbitrate who can talk
to who or through positive decoding (don’t bother what it means if you don’t
know hardware well enough). Serial bus use framed message to do the same
(positive decoding). Does your hardware contain thing that can be called
bus? If it does not, don’t use bus driver to model your hardware.

Your hardware may be a multifunction device. Normally one need to implement
a driver for each functional device. Any Southbridge on your computer is
such a beast, So does digital still camera, just as an example. Anyway in
order to write driver for your hardware, you must first understand how to
use device node method to logically describe your driver.

A legacy device driver is NT 4.0 device driver that does not support
PnP/Power Management. For PCI like device, you have to enumerate devices on
the bus to see which one is yours. There are a lot of examples on how to do
that.

Good luck.

Bi

Chris:

Your hardware seems like a multifunction device hardware. I don’t understand
how your driver can be unloaded if one of the device object handle is still
hold by someone. The reference counting on Driver should be the sum of all
device. That is in any of your device IRP_MJ_CREATE, you call
ObReferenceObject(pDriver) and every IRP_MJ_CLOSE you call
ObDereferenceObject(pDriver). I thought Microsoft would do it in AddDevice
or at least in IRP_MJ_PNP IRP_MN_START_DEVICE is called IRP_MN_REMOVE_DEVICE
but it does not hurt to do it one more time by yourself.

One thing I don’t understand is how could you receive a call
IRP_MJ_PNP/IRP_MN_QUERY_REMOVE_DEVICE and IRP_MN_REMOVE_DEVICE if you don’t
have a bus driver that invalidates a PDO. If you delete a device, the only
thing you save is the device object and everyhing in the device extension.
That is not much memory. You don’t save any code/data memory at all. I would
keep the device objects around and just put them to D3 if they are not used.

Bi

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Tuesday, September 10, 2002 2:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

I will take another stab at explaining my situation with some more details
about what I want to do and my reasons.

My device hosts child devices, so that is why I am creating it as a bus
architecture.
Applications can open handles to the children to do reads/writes etc. (doing
so to the bus device makes no sense so I’ll ignore the possibility in this
explaination).

Now, normally I would just make the function driver of the bus device a bus
driver that creates the child PDO’s etc. This is what I had originally done.

Next came some problems when testing hibernation and standby. Because of
the way the hardware is designed, returning from hibernation causes the bus
device’s driver to be unloaded and reloaded (and all children of course).
This unload and reload cannot be stopped and for the purposes of my problem
should be treated as etched in stone. It’s like the device is surprise
removed from the system and then placed back in.

Now, when there are no handles open to the child devices everything goes
fine because the drivers can unload and reload without a problem. However,
if there are open handles, the drivers cannot unload properly and the device
cannot be restarted.

Here lies my reasons for wanting to move the bus to a root-enumerated-like
architecture. If the children are not on the same stack as the bus device,
then the bus device’s driver can unload and reload after a hibernation
without disturbing the children and their open handles.

I believe I came up with a solution today that would fix my problems but, as
always, alternate suggestions are welcome (why else would I be posting this
:).
From here on “Device” refers to the actual bus device that is plugged into
the system.
When the device is first plugged in, it’s driver co-installer first installs
the virtual bus (I could do this like you would if you installed the toaster
bus using devcon). Once the virtual bus is installed the system would
continue installing the device’s driver. This driver would proceed to start
the device and communicate to the virtual bus all the required information
about the children. The virtual bus would respond by creating the children
and reporting them after a call to IoInvalidateBusRelations.

When the system goes into hibernation the device’s driver signals the
virtual bus that it needs to treat the hardware as untouchable. The device’s
driver can unload and reload without a problem after returning from
hibernation. It can then “re-connect” to the virtual bus and get things
going again.

If you think about it, what I am trying to do is very similar to toaster
except that I need to control the virtual bus from a device driver instead
of a user mode app.

***Whatever solution I end up with must be signable.***

Thanks for everyone’s help in this matter, you have been giving me great
ideas to investigate.
Again, more ideas are very much welcome…I wouldn’t call myself an expert
on this stuff.
Chris


“Bi Chen” wrote in message news:xxxxx@ntdev…
Hi, Chris:

I think you are bit confused with PnP and device node tree. If you can read
DDK PnP section, you will gain a lot of PnP understanding, especially if you
have not done any WDM/PnP driver.

A bus driver such as toaster can instantiate PDO based on the external
signal (fake bus driver such as toaster is response to external human
signal). It also reposible for turn on and off bus power supply (PCI 2.1,
2.2, USB, 1394) to specific device (slot, hub) connected on the bus. Bus
allows many devices connected to it to commuincate with host or each other.
Parallel bus uses out-of-band signal (extra wires) to arbitrate who can talk
to who or through positive decoding (don’t bother what it means if you don’t
know hardware well enough). Serial bus use framed message to do the same
(positive decoding). Does your hardware contain thing that can be called
bus? If it does not, don’t use bus driver to model your hardware.

Your hardware may be a multifunction device. Normally one need to implement
a driver for each functional device. Any Southbridge on your computer is
such a beast, So does digital still camera, just as an example. Anyway in
order to write driver for your hardware, you must first understand how to
use device node method to logically describe your driver.

A legacy device driver is NT 4.0 device driver that does not support
PnP/Power Management. For PCI like device, you have to enumerate devices on
the bus to see which one is yours. There are a lot of examples on how to do
that.

Good luck.

Bi


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

>Your hardware seems like a multifunction device hardware. I don’t
understand

how your driver can be unloaded if one of the device object handle is still
hold by someone. The reference counting on Driver should be the sum of all
device. That is in any of your device IRP_MJ_CREATE, you call
ObReferenceObject(pDriver) and every IRP_MJ_CLOSE you call
ObDereferenceObject(pDriver). I thought Microsoft would do it in AddDevice
or at least in IRP_MJ_PNP IRP_MN_START_DEVICE is called
IRP_MN_REMOVE_DEVICE
but it does not hurt to do it one more time by yourself.

Your right…it can’t be unloaded. However, like I said, the hardware design
makes the system believe that the hardware was surprise removed and then
plugged back in. The driver does not try to unload immediately but it does
as soon as all open handles are closed. A more accurate description of what
happens is that the system “sees” the device as being swapped for a
different one during the hibernated state. This is what starts the unloading
process.

One thing I don’t understand is how could you receive a call
IRP_MJ_PNP/IRP_MN_QUERY_REMOVE_DEVICE and IRP_MN_REMOVE_DEVICE if you don’t
have a bus driver that invalidates a PDO. If you delete a device, the only
thing you save is the device object and everyhing in the device extension.
That is not much memory. You don’t save any code/data memory at all. I
would
keep the device objects around and just put them to D3 if they are not
used.

I don’t quite follow you on this part.
Which device object are you referring to, the bus FDO, child PDO or child
FDO?
Why don’t I have a bus driver that invalidates the PDOs?

…Chris

-----Original Message-----
From: Chris Doré [mailto:xxxxx@connecttech.com]
Sent: Tuesday, September 10, 2002 2:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

I will take another stab at explaining my situation with some more details
about what I want to do and my reasons.

My device hosts child devices, so that is why I am creating it as a bus
architecture.
Applications can open handles to the children to do reads/writes etc. (doing
so to the bus device makes no sense so I’ll ignore the possibility in this
explaination).

Now, normally I would just make the function driver of the bus device a bus
driver that creates the child PDO’s etc. This is what I had originally done.

Next came some problems when testing hibernation and standby. Because of
the way the hardware is designed, returning from hibernation causes the bus
device’s driver to be unloaded and reloaded (and all children of course).
This unload and reload cannot be stopped and for the purposes of my problem
should be treated as etched in stone. It’s like the device is surprise
removed from the system and then placed back in.

Now, when there are no handles open to the child devices everything goes
fine because the drivers can unload and reload without a problem. However,
if there are open handles, the drivers cannot unload properly and the device
cannot be restarted.

Here lies my reasons for wanting to move the bus to a root-enumerated-like
architecture. If the children are not on the same stack as the bus device,
then the bus device’s driver can unload and reload after a hibernation
without disturbing the children and their open handles.

I believe I came up with a solution today that would fix my problems but, as
always, alternate suggestions are welcome (why else would I be posting this
:).
From here on “Device” refers to the actual bus device that is plugged into
the system.
When the device is first plugged in, it’s driver co-installer first installs
the virtual bus (I could do this like you would if you installed the toaster
bus using devcon). Once the virtual bus is installed the system would
continue installing the device’s driver. This driver would proceed to start
the device and communicate to the virtual bus all the required information
about the children. The virtual bus would respond by creating the children
and reporting them after a call to IoInvalidateBusRelations.

When the system goes into hibernation the device’s driver signals the
virtual bus that it needs to treat the hardware as untouchable. The device’s
driver can unload and reload without a problem after returning from
hibernation. It can then “re-connect” to the virtual bus and get things
going again.

If you think about it, what I am trying to do is very similar to toaster
except that I need to control the virtual bus from a device driver instead
of a user mode app.

***Whatever solution I end up with must be signable.***

Thanks for everyone’s help in this matter, you have been giving me great
ideas to investigate.
Again, more ideas are very much welcome…I wouldn’t call myself an expert
on this stuff.
Chris


“Bi Chen” wrote in message news:xxxxx@ntdev…
Hi, Chris:

I think you are bit confused with PnP and device node tree. If you can read
DDK PnP section, you will gain a lot of PnP understanding, especially if you
have not done any WDM/PnP driver.

A bus driver such as toaster can instantiate PDO based on the external
signal (fake bus driver such as toaster is response to external human
signal). It also reposible for turn on and off bus power supply (PCI 2.1,
2.2, USB, 1394) to specific device (slot, hub) connected on the bus. Bus
allows many devices connected to it to commuincate with host or each other.
Parallel bus uses out-of-band signal (extra wires) to arbitrate who can talk
to who or through positive decoding (don’t bother what it means if you don’t
know hardware well enough). Serial bus use framed message to do the same
(positive decoding). Does your hardware contain thing that can be called
bus? If it does not, don’t use bus driver to model your hardware.

Your hardware may be a multifunction device. Normally one need to implement
a driver for each functional device. Any Southbridge on your computer is
such a beast, So does digital still camera, just as an example. Anyway in
order to write driver for your hardware, you must first understand how to
use device node method to logically describe your driver.

A legacy device driver is NT 4.0 device driver that does not support
PnP/Power Management. For PCI like device, you have to enumerate devices on
the bus to see which one is yours. There are a lot of examples on how to do
that.

Good luck.

Bi


You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

-----Original Message-----
From: Chris Dor? [mailto:xxxxx@connecttech.com]
Sent: Wednesday, September 11, 2002 6:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

Your hardware seems like a multifunction device hardware. I don’t
understand
how your driver can be unloaded if one of the device object handle is still
hold by someone. The reference counting on Driver should be the sum of all
device. That is in any of your device IRP_MJ_CREATE, you call
ObReferenceObject(pDriver) and every IRP_MJ_CLOSE you call
ObDereferenceObject(pDriver). I thought Microsoft would do it in AddDevice
or at least in IRP_MJ_PNP IRP_MN_START_DEVICE is called
IRP_MN_REMOVE_DEVICE
but it does not hurt to do it one more time by yourself.

Your right…it can’t be unloaded. However, like I said, the hardware design
makes the system believe that the hardware was surprise removed and then
plugged back in. The driver does not try to unload immediately but it does
as soon as all open handles are closed. A more accurate description of what
happens is that the system “sees” the device as being swapped for a
different one during the hibernated state. This is what starts the unloading
process.

Chirs: does that mean you hardware does not follow the normal device
hardware power up procedure during the PC POST (Power On Self Test) stage? I
assume your hardware has no problem during normal PC power cycle. I think it
must be when system is going to hibernating state, some thing nonvolatile is
written in your hardware so it does not do the power up as quickly as it
should. Therefore, when bus driver enumerate the bus and does not see this
device, it call IoInvalidateDeviceRelations to the PDO of this device,
thinking user has removed it when system is in hibernate state. After a
while your hardware is powered on and physical bus get a notification of a
device plug-in event and there goes the chain event lead to the AddDevice
and so on.

If that is the case, try not to do anything in the power transition except
reset and power-down the device and save any context info on disk. When
device gets power up, reset and restore the context that is saved on the
disk before let it loose to perform any incoming/pending operation. If there
are pending operations on your hardware when your driver recieve D0 to
D1,2,3 state, simply keep IRP and reset the hardware. The next time it is
powered on (from suspend or hibernate), you can retry those IRPs.

Bi

Bi

Bi,

The bus that the device is attached to determines that the device has been
swapped because of a change in identity. It is a basic enumeration issue,
the bus actually sees the device as being a completely different device
after returning from hibernation. I have looked into stopping the bus from
issuing the remove but it isn’t possible with any type of filters (I
probably could but it would be more work than going around the problem and
would be very sensitive to any changes MS made to the bus drivers…icky
stuff).

For the purposes of this problem you just have to trust me when I say it
can’t be “fixed” and that I need a way to get around the issue instead of
going through it :slight_smile:

Thanks, Chris

“Bi Chen” wrote in message news:xxxxx@ntdev…

-----Original Message-----
From: Chris Doré [mailto:xxxxx@connecttech.com]
Sent: Wednesday, September 11, 2002 6:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Driver starting another.

>Your hardware seems like a multifunction device hardware. I don’t
understand
>how your driver can be unloaded if one of the device object handle is still
>hold by someone. The reference counting on Driver should be the sum of all
>device. That is in any of your device IRP_MJ_CREATE, you call
>ObReferenceObject(pDriver) and every IRP_MJ_CLOSE you call
>ObDereferenceObject(pDriver). I thought Microsoft would do it in AddDevice
>or at least in IRP_MJ_PNP IRP_MN_START_DEVICE is called
IRP_MN_REMOVE_DEVICE
>but it does not hurt to do it one more time by yourself.

Your right…it can’t be unloaded. However, like I said, the hardware design
makes the system believe that the hardware was surprise removed and then
plugged back in. The driver does not try to unload immediately but it does
as soon as all open handles are closed. A more accurate description of what
happens is that the system “sees” the device as being swapped for a
different one during the hibernated state. This is what starts the unloading
process.

Chirs: does that mean you hardware does not follow the normal device
hardware power up procedure during the PC POST (Power On Self Test) stage? I
assume your hardware has no problem during normal PC power cycle. I think it
must be when system is going to hibernating state, some thing nonvolatile is
written in your hardware so it does not do the power up as quickly as it
should. Therefore, when bus driver enumerate the bus and does not see this
device, it call IoInvalidateDeviceRelations to the PDO of this device,
thinking user has removed it when system is in hibernate state. After a
while your hardware is powered on and physical bus get a notification of a
device plug-in event and there goes the chain event lead to the AddDevice
and so on.

If that is the case, try not to do anything in the power transition except
reset and power-down the device and save any context info on disk. When
device gets power up, reset and restore the context that is saved on the
disk before let it loose to perform any incoming/pending operation. If there
are pending operations on your hardware when your driver recieve D0 to
D1,2,3 state, simply keep IRP and reset the hardware. The next time it is
powered on (from suspend or hibernate), you can retry those IRPs.

Bi

Bi