[driver-discuss] Is it possible for two drivers to depend on each other?

Bart Smaalders bart.smaalders at Sun.COM
Thu Feb 8 19:20:20 PST 2007


Freeman.Liu at sun.com wrote:
> Bart Smaalders wrote:
> 
>> LiuFeng wrote:
>>
>>> Good day, everyone!
>>>
>>> I have a question here.
>>> I have two drivers, say A and B, that cooperate to provide a specific 
>>> funcationality. A can call a routine provided by B and passes in a 
>>> callback as a parameter so that B can use that to call into A. From 
>>> this point of view, they behavior like module. Such calls could be 
>>> issued even before the drivers create minor nodes. Yet I can only 
>>> create one-way dependency, say A depends on B. The issues is: it's 
>>> possible that A could be unloaded, which is very possible with debug 
>>> kernel, when B call into A. And the system will panic.
>>>
>>
>> Before handing out a function pointer for callback, you need
>> to make sure your module cannot be unloaded until the callback
>> is explicitly disabled....
> 
> Yes, could you explain more about how to make it sure ?

http://developers.sun.com/solaris/developer/support/driver/faqs.html#QA3.28

3.28  Under certain conditions on the Solaris OS, a device driver cannot 
be unloaded. What are those conditions?

     * If a driver has no detach routine (nodev is specified in the 
driver's dev_ops(9S) for its detach routine).
     * If EBUSY is returned from the driver's _fini() routine.
     * If the driver has a positive number of references to it.
     * If the driver has a bus_ops structure specified in its dev_ops 
structure, and it has children attached to it (therefore it is a nexus 
driver).
     * If the driver has no dev_ops at all!


So if your detach routine returns DDI_FAILURE rather than
DDI_SUCCESS, you can prevent your module from unloading...

For an example see:

http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/devpool.c#pool_detach


- Bart

-- 
Bart Smaalders			Solaris Kernel Performance
barts at cyber.eng.sun.com		http://blogs.sun.com/barts



More information about the driver-discuss mailing list