Brook Milligan wrote:
> tsleep()/wakeup() sounds like just the right thing.  I note that the
> dev/if_wi.c driver uses an idle loop instead, though.  Is this because
> the response will come so soon that tsleep() is not worth it?  How
> long must the expected wait be before tsleep() is preferable?

The issue here is the minimum time quantum you can sleep in tsleep()
is one tick.  The 'tick' time value quantum is machine-dependant
and depends on HZ.  For example: i386 has HZ=100 commonly, i.e.
one tick is 10ms. Alpha has HZ=1000, i.e. one tick is 1ms. Thus, tsleep()
might not be too suitable if you'd need to poll a device and need
to find out a condition happened as fast as possible. If you don't
care about milisecond here and milisecond there, tsleep() is okay :)

Also, don't forget you'd need a process context if you want
to use tsleep(). You can't use tsleep() from interrupt context -
you'd either use random process context which happens to be running,
or panic if the machine would otherwise be idling at the moment.
The canonic way is to use kthreads for this (see kthread(9)).
 
Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!