On Fri, 2007-06-15 at 14:03 -0400, Zhu Han wrote:
> On 6/15/07, Kieran Mansley <[EMAIL PROTECTED]> wrote:
> >
> > The lock protects the use_count variable. The use_count variable
> > prevents the plugin module unloading while it is being used. I couldn't
> > just use the lock to prevent the modul
On 6/15/07, Kieran Mansley <[EMAIL PROTECTED]> wrote:
The lock protects the use_count variable. The use_count variable
prevents the plugin module unloading while it is being used. I couldn't
just use the lock to prevent the module unloading as the hook function
(i) might block (and holding a s
On 15/6/07 17:22, "Kieran Mansley" <[EMAIL PROTECTED]> wrote:
> The lock protects the use_count variable.
Yes, that's one thing I noticed -- can you use atomic_t for reference counts
and hence reduce the number of times you need to lock/unlock? At least the
open-coded lock-decrement-test-maybe-fr
On Fri, 2007-06-15 at 11:59 -0400, Zhu Han wrote:
> Hi, Kieran,
>
> I'm just wonder why you try to acquire the lock and increase the
> hooks_usecount each time when you use the hook routine. Is there any
> generic ways to synchronze the code path using hook routines and
> netfront_accelerator_unlo
On Fri, 15 Jun 2007 11:59:43 -0400
"Zhu Han" <[EMAIL PROTECTED]> wrote:
> Hi, Kieran,
>
> I'm just wonder why you try to acquire the lock and increase the
> hooks_usecount each time when you use the hook routine. Is there any
> generic ways to synchronze the code path using hook routines and
> ne
Hi, Kieran,
I'm just wonder why you try to acquire the lock and increase the
hooks_usecount each time when you use the hook routine. Is there any
generic ways to synchronze the code path using hook routines and
netfront_accelerator_unloaded, considering you can synchronize the
tx/rx data path eas
