kldunload DIAGNOSTIC idea...

[Doug Rabson]

On Wed, 2004-07-21 at 12:02, Poul-Henning Kamp wrote:
> In message <1090406270.7114.2.camel at builder02.qubesoft.com>, Doug Rabson writes
> :
> >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote:
> >> In message <200407211010.08159.dfr at nlsystems.com>, Doug Rabson writes:
> >> 
> >> >The original intention was that drivers use the 
> >> >device_busy()/device_unbusy() counter to handle these things. In some 
> >> >cases, just calling device_busy() from fooopen() and device_unbusy() 
> >> >from fooclose() is sufficient.
> >> 
> >> That is not enough.  All methods in cdevsw, and things not in cdevsw
> >> (clone handlers, call backs, etc etc) needs to refcount.
> >> 
> >> I have a lot of this working in a tree here, and will commit it once
> >> I have gone over it a few more times.
> >
> >Methods in cdevsw which can't be called unless the device is opened can
> >rely on a single counter managed by open/close in most cases. Other
> >callbacks may or may not need extra handling depending on whether or not
> >the callback can persist past close.
> 
> The problem is that if you are sleeping in for instance a read, you
> need to wake up the thread, and you can still only hope that it
> will at some point in the future do a close.
> 
> That is why the devsw/cdev code is designed so that you can forego
> your close (and do it yourself) by destroying the cdev.  You still
> need to evict all threads of course, but you don't need to wait
> (potentially for ever) for them to come back and call close.
> 
> >Will you use the existing device_busy() counter or will each driver use
> >its own counter?
> 
> device_busy doesn't work well because it cannot happen until I am
> already inside the driver and because there is no known relationship
> between cdevs and device_t's.
> 
> There are three parts to it, a refcount on cdevsw which tells us if
> any thread is inside the driver using that route, a refcount on the
> individual cdev and a linkage between the two.

The device_busy() counter is still simplest (as long as there is a
device_t at all). The implementation of devclass_delete_driver() will
automatically veto the unload (when its called from
driver_module_handler()).