>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%%