Hello,
I have two drivers which need to share a few variables with each other.
One driver would only write to, the other one would only read them.
Basically, I just need some non-paged memory identifiable by a name or similar.
Both drivers should be able to allocate/claim it, because no load order is guaranteed,
and it should be freed (including the identification) when both drivers are unloading/dereferencing it.
A callback would certainly work, but I think that’s too powerful for this simple requirement.
How would you implement this?
Thanks.
> A callback would certainly work, but I think that’s too powerful for this simple
requirement.
I don’t think it can get done without callbacks and IOCTLs (in order to register a callback with a driver X, driver Y needs to send it IOCTL anyway)…
Anton Bassov
xxxxx@hushmail.com wrote:
Hello,
I have two drivers which need to share a few variables with each other.
One driver would only write to, the other one would only read them.
Basically, I just need some non-paged memory identifiable by a name or similar.
Both drivers should be able to allocate/claim it, because no load order is guaranteed,
and it should be freed (including the identification) when both drivers are unloading/dereferencing it.
A callback would certainly work, but I think that’s too powerful for this simple requirement.
It is not such a simple requirement. A shared kernel dll would do it,
but the dll would not unload itself, although it could reference count
the memory objects and allocate them/free them as appropriate.
How would you implement this?
Thanks.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> A shared kernel dll would do it
I think that registering a custom calback is easier that using a shared DLL. The only issue that adds a bit of complexity here is possible inter-dependency, i.e. the scenario when driver X gets unloaded while driver Y still needs it (if they simply increment refcount on one another in order to deal with it, they may get into the circular reference problem), but still it can get resolved with not-so-terribly complex workaround…
Anton Bassov
Thanks for your replies!
Mark Roddy wrote:
A shared kernel dll would do it […].
That’s not an option. The relationship between both drivers is not vital,
i.e., even if one driver is missing, the other one should keep running with limited functionality.
Anton Bassov wrote:
The only issue that adds a bit of complexity here is possible inter-dependency, i.e.
the scenario when driver X gets unloaded while driver Y still needs it (if they
simply increment refcount on one another in order to deal with it, they may get
into the circular reference problem), but still it can get resolved with
not-so-terribly complex workaround…
I think that doesn’t apply in my scenario.
To clear things up:
I have one “master” driver that does the actual work.
The other one, my “slave” driver, is attached to a different device stack.
The slave’s sole purpose is to save a few (namely two) pointers the master is interested in.
Although there are other ways for the master to get these addresses, this is the only legit way.
The slave writes to both variables, the master reads them.
If the slave unloads, it would simply set the variables to zero, the master checks them
and would just skip the functionality the pointers are needed for.
I have been thinking about creating my own section object, but I’d like to stay on the documented road.
> If the slave unloads, it would simply set the variables to zero, the master checks them
Then they must either reside in master’s module, or master should must increment refcount on the slave - otherwise, you will BSOD if master checks these variables after slave has been already unloaded…
I would do everything in a master - slave would send it an IOCTL and get the address of a callback function that it can call (variables would get modified by this function), but this function itself would be implemented in a master, and, hence, variables would reside in master’s module. If you assume that master cannot get unloaded while slave is still around (for example, it just does not provide DrvUnload() routine), this is all you need here…
Anton Bassov
You could put your shared variables in a Driver Extension. Driver A would create it and Driver B could look for it, I’ve used this method many times.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, July 14, 2007 5:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share variables between two drivers?
If the slave unloads, it would simply set the variables to zero, the master checks them
Then they must either reside in master’s module, or master should must increment refcount on the slave - otherwise, you will BSOD if master checks these variables after slave has been already unloaded…
I would do everything in a master - slave would send it an IOCTL and get the address of a callback function that it can call (variables would get modified by this function), but this function itself would be implemented in a master, and, hence, variables would reside in master’s module. If you assume that master cannot get unloaded while slave is still around (for example, it just does not provide DrvUnload() routine), this is all you need here…
Anton Bassov
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
The Driver Extension is allocated, per the drivers request, within the
DRIVER_OBJECT, and will still need synchronization and reference control to
be sure those values are not accessed when the driver object is removed.
Using a driver extension is a means of allocating, not controlling access.
Nothing keeps Driver A from being removed while Drive B is using the pointer
to the extension it fetched before Driver A was torn down. Plus, you cannot
get the extension while at DIRQL.
–
The personal opinion of
Gary G. Little
“Mark Rodriquez” wrote in message
news:xxxxx@ntdev…
You could put your shared variables in a Driver Extension. Driver A would
create it and Driver B could look for it, I’ve used this method many times.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, July 14, 2007 5:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share variables between two drivers?
> If the slave unloads, it would simply set the variables to zero, the
> master checks them
Then they must either reside in master’s module, or master should must
increment refcount on the slave - otherwise, you will BSOD if master checks
these variables after slave has been already unloaded…
I would do everything in a master - slave would send it an IOCTL and get the
address of a callback function that it can call (variables would get
modified by this function), but this function itself would be implemented in
a master, and, hence, variables would reside in master’s module. If you
assume that master cannot get unloaded while slave is still around (for
example, it just does not provide DrvUnload() routine), this is all you need
here…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer