Re: kldunload DIAGNOSTIC idea...

From: Doug Rabson (dfr_at_nlsystems.com)
Date: 07/21/04

  • Next message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..." 
    To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 21 Jul 2004 12:20:54 +0100

    On Wed, 2004-07-21 at 12:02, Poul-Henning Kamp wrote:
    > In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes
    > :
    > >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote:
    > >> In message <200407211010.08159.dfr@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()).

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."

    Relevant Pages

    • Re: kldunload DIAGNOSTIC idea...
      ... >>Methods in cdevsw which can't be called unless the device is opened can ... >>callbacks may or may not need extra handling depending on whether or not ... > your close by destroying the cdev. ... > any thread is inside the driver using that route, a refcount on the ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... All methods in cdevsw, ... >> needs to refcount. ... your close by destroying the cdev. ... already inside the driver and because there is no known relationship ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... All methods in cdevsw, ... >> needs to refcount. ... your close by destroying the cdev. ... already inside the driver and because there is no known relationship ...
      (freebsd-arch)
    • Im counting my threads, one, two, three, four, five... [1]
      ... cdev and consequently, with a bit of adding up, also for each cdevsw. ... The next step is to add a new method to the cdevsw which purges threads ... and exit the driver with ENXIO error return. ... hardware without panicing in the lower layers of the kernel. ...
      (freebsd-arch)
    • Re: Re[2]: HEADSUP: linux dev_t emulation
      ... >A translation table probably? ... If so then the table will have to key off the name in the cdevsw ... associated with the cdev since our major/minor numbers are no longer ... Never attribute to malice what can adequately be explained by incompetence. ...
      (freebsd-arch)