Re: kldunload DIAGNOSTIC idea...
From: Doug Rabson (dfr_at_nlsystems.com)
Date: 07/21/04
- Previous message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Poul-Henning Kamp <phk@phk.freebsd.dk> Date: Wed, 21 Jul 2004 11:37:50 +0100
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.
Will you use the existing device_busy() counter or will each driver use
its own counter?
_______________________________________________
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"
- Previous message: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Reply: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: kldunload DIAGNOSTIC idea...
... >>The original intention was that drivers use the ... >>from fooclose()
is sufficient. ... All methods in cdevsw, ... callbacks may or may not need
extra handling depending on whether or not ... (freebsd-arch) - Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)
... by bus types / driver types that don't need to implement the _noirq callbacks. ...
Both the platform and PCI bus types generally allow drivers to use _noirq ... Yes, the
changelog is wrong, because I used a separate structure for the ... from hibernation or
a suspend/hibernation failure etc.?). ... (Linux-Kernel) - Re: More hardware monitoring drivers ported to the new sysfs callbacks
... > take benefit of Yani Ioannou's new, extended sysfs callbacks. ... >
drivers, with significant benefits. ... extra space required for a sensor device
attribute. ... send the line "unsubscribe linux-kernel" in ... (Linux-Kernel) - Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)
... device drivers' ->resumecallbacks. ... from hibernation or a suspend/hibernation
failure etc.?). ... Several driver power state transitions are externally visible,
... (Linux-Kernel) - 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)