kldunload DIAGNOSTIC idea...

[Poul-Henning Kamp]

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.