On Wed, Jun 20, 2007 at 11:07:26AM +0100, Andrew Doran wrote:
> Hi,
> 
> Something else occured to me. Since callouts will be able to block on locks,
> then the interfaces used to manage the callouts have to be able to block
> also. That means it won't be possible to schedule a callout directly from a
> hardware interrupt handler.

Do you mean 'run the callout function' ?
Isn't that done from the soft timer interrupt anyway?
 
> The reason being, the callout routines (like callout_stop()) shouldn't
> return until the callout has stopped executing. Currently we spin if a
> callout is running on another CPU.

Yes SVR4 did that, and it was a right PITA.
If (and I assume it is) callout_stop() can be called with a driver mutex
held, then having a try_callout_stop() would help.

The other issue came with periodic timers (which I don't think NetBSD has)
where the callout function couldn't cancel its own timer.
 
> This should also fix the issue with callouts being cancelled from a higher
> priority interrupt. For example while taking a soft interrupt at splsoftnet
> we can do the following while a callout is running on the local CPU and
> operating on 'item':
> 
> 	callout_stop(&item->ch);
> 	pool_put(item);
> 
> Thoughts?
> 
> Andrew


	David

-- 
David Laight: david@l8s.co.uk