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.

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.

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