Re: kldunload DIAGNOSTIC idea...

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 07/21/04

  • Next message: Doug Rabson: "Re: kldunload DIAGNOSTIC idea..." 
    To: Doug Rabson <dfr@nlsystems.com>
Date: Wed, 21 Jul 2004 13:02:41 +0200

    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. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@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.
_______________________________________________
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: Doug Rabson: "Re: kldunload DIAGNOSTIC idea..."

    Relevant Pages

    • 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: 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...
      ... >>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: 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)