Just wondering here - for pseudo-devices, is it really necessary to
remove the autoconf stuff at all? It's not clear to me where it even
gets added in the case of modularly-loaded pseudo-devices...
Yes. See, e.g., cgd_modcmd. In addition to cgd_cdevsw, there is also
a struct cfdriver obj
Date: Thu, 9 Jun 2016 07:12:08 +0800 (PHT)
From: Paul Goyette
For now, I'm just going to maintain a zero/non-zero "active" flag in the
driver, setting it on open() and clearing on close().
Unloading of the module will first call devsw_detach(), and then check
the flag. If th
Thanks, everyone, for clarifying this confusing-to-me situation!
For now, I'm just going to maintain a zero/non-zero "active" flag in the
driver, setting it on open() and clearing on close().
Unloading of the module will first call devsw_detach(), and then check
the flag. If the flag is set,
On Wed, 8 Jun 2016, Robert Elz wrote:
Date:Wed, 8 Jun 2016 22:16:28 +0800 (PHT)
From:Paul Goyette
Message-ID:
| Hmmm. Would it be valid, then, for my close() routine to reset the
| ref-count to zero rather than simply decrementing?
Do you really need a reference
p...@whooppee.com (Paul Goyette) writes:
>On Wed, 8 Jun 2016, Michael van Elst wrote:
>> p...@whooppee.com (Paul Goyette) writes:
>>
See misfs/specfs/spec_vnops.c::spec_close().
>>
>>> yes, that would certainly explain the situation. It does, however, make
>>> it rather difficult to maintai
Date: Wed, 8 Jun 2016 17:34:33 +
From: David Holland
On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote:
> Can anyone suggest a reliable way to ensure that a device-driver module
can
> be _really_ safely detached?
There's a pserialize scheme for this; see e.g.
Date: Wed, 8 Jun 2016 19:47:38 +0800 (PHT)
From: Paul Goyette
For some reason, the device's open() routine is being called twice, but
the close() routine is only called once. So every iteration leaves the
refcount with a net increment of one.
Correct! But, counterintuitively,
On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote:
> Can anyone suggest a reliable way to ensure that a device-driver module can
> be _really_ safely detached?
There's a pserialize scheme for this; see e.g. an old thread called
"kicking everybody out of the softc".
The catch for arbi
Date:Wed, 8 Jun 2016 22:16:28 +0800 (PHT)
From:Paul Goyette
Message-ID:
| Hmmm. Would it be valid, then, for my close() routine to reset the
| ref-count to zero rather than simply decrementing?
Do you really need a reference count for anything? Wasn't that j
> On Jun 8, 2016, at 10:16 AM, Paul Goyette wrote:
>
> On Wed, 8 Jun 2016, Michael van Elst wrote:
>
>> p...@whooppee.com (Paul Goyette) writes:
>>
See misfs/specfs/spec_vnops.c::spec_close().
>>
>>> yes, that would certainly explain the situation. It does, however, make
>>> it rather d
On Wed, 8 Jun 2016, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
See misfs/specfs/spec_vnops.c::spec_close().
yes, that would certainly explain the situation. It does, however, make
it rather difficult to maintain a valid ref-count!
specfs does the open refcounting. T
> I'll try to lookup chapter and verse for you in the next week or so
6.2, 197--198.
p...@whooppee.com (Paul Goyette) writes:
>> See misfs/specfs/spec_vnops.c::spec_close().
>yes, that would certainly explain the situation. It does, however, make
>it rather difficult to maintain a valid ref-count!
specfs does the open refcounting. The device only has a single bit, open
sets it
tegy for device deletion (also see PR kern/48536)
} On Wed, 8 Jun 2016, Paul Goyette wrote:
}
} > On Tue, 7 Jun 2016, Taylor R Campbell wrote:
} >
} >> Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
} >> From: Paul Goyette
} >>
} >> Can anyone suggest a relia
On Wed, 8 Jun 2016, J. Hannken-Illjes wrote:
Well, it almost works! Just one little problem... :)
For some reason, the device's open() routine is being called twice, but the
close() routine is only called once. So every iteration leaves the refcount
with a net increment of one.
I cannot f
> On 08 Jun 2016, at 13:47, Paul Goyette wrote:
>
> On Wed, 8 Jun 2016, Paul Goyette wrote:
>
>> On Tue, 7 Jun 2016, Taylor R Campbell wrote:
>>
>>> Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
>>> From: Paul Goyette
>>>
>>> Can anyone suggest a reliable way to ensure that a device-driver m
On Wed, 8 Jun 2016, Paul Goyette wrote:
On Tue, 7 Jun 2016, Taylor R Campbell wrote:
Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
From: Paul Goyette
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
General approach:
1. Prevent n
>that one i think is a much larger issue that affects *all* of our
>drivers and needs a general fix where eg device_lookup_private()
>returns a reference counted value that must be returned, before the
>module can be considered ready to unload (this still leaves a very
>minor ra
Date: Wed, 08 Jun 2016 04:42:21 +1000
from: matthew green
that one i think is a much larger issue that affects *all* of our
drivers and needs a general fix where eg device_lookup_private()
returns a reference counted value that must be returned, before the
module can be consider
On Tue, 7 Jun 2016, Taylor R Campbell wrote:
Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
From: Paul Goyette
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
General approach:
1. Prevent new references (e.g., devsw_detach).
2. Wa
On Tue, 7 Jun 2016, David Young wrote:
On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote:
Can anyone suggest a reliable way to ensure that a device-driver
module can be _really_ safely detached?
The module could theoretically maintain an open/ref counter, but
making this MP-safe is
Date: Tue, 7 Jun 2016 18:28:11 +0800 (PHT)
From: Paul Goyette
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
General approach:
1. Prevent new references (e.g., devsw_detach).
2. Wait for existing references to drain (or rol
Paul Goyette writes:
> Can anyone suggest a reliable way to ensure that a device-driver module
> can be _really_ safely detached?
the method the USB drivers use seems to be fairly safe. there's one
condition i'm not 100% sure about, but seems unlikely.
see the usage of eg, sc_dying in ugen.c.
On Tue, Jun 07, 2016 at 06:28:11PM +0800, Paul Goyette wrote:
> Can anyone suggest a reliable way to ensure that a device-driver
> module can be _really_ safely detached?
>
> The module could theoretically maintain an open/ref counter, but
> making this MP-safe is "difficult"! Even if the module
On Tue, 7 Jun 2016, David Brownlee wrote:
Any good MP-safe suggestions?
Other than having the mutex be for a nullable pointer to the device
which persists after driver detach and is reattached when the driver
reattaches, which adds an extra pointer dereference for every use...
:/
Well, yeah,
On 7 June 2016 at 11:28, Paul Goyette wrote:
> Can anyone suggest a reliable way to ensure that a device-driver module can
> be _really_ safely detached?
>
> The module could theoretically maintain an open/ref counter, but making this
> MP-safe is "difficult"! Even if the module were to provide a
Can anyone suggest a reliable way to ensure that a device-driver module
can be _really_ safely detached?
The module could theoretically maintain an open/ref counter, but making
this MP-safe is "difficult"! Even if the module were to provide a mutex
to control increment/decrement of it's count
27 matches
Mail list logo
