最近在fix一個bug，說起來挺簡單。driver中用到了drv_usecwait（），這個函數是busy-wait，也就是占住CPU，直到指定的時間耗完。如果等待的時間很長，這對CPU資源將是一種很大的浪費。所以需要用其它delay方法。其中就有deay(9F)調用。
delay(9F)在使用中有種種限制，首先，它不能在interrupt context中調用。第一次的fix沒有注意到這一點。被codereviewer指出來了。其次，它不能用於polled模式下，在polled模式下，“when system enters standalone mode, only one CPU and one thread keep active. Timesharing, interrupts and system services are turned off.” delay(9F)使用了timeout(9F)，這是通過一個中斷服務線程實現的。再次，在dev_ops的devo_reset 函數中也不能調用delay。因為devo_reset會被reset_leaves調到，即系統重啟或關閉時，在文件86pc/os/machdep.c中可看到相關注釋：
mdboot(int cmd, int fcn, char *mdep, boolean_t invoke_cb)
QUOTE: /*
* stop other cpus and raise our priority. since there is only
* one active cpu after this, and our priority will be too high
* for us to be preempted, we're essentially single threaded
* from here on out.
*/ 此時，系統處於單線程，單cpu狀態， 與polled模式相同。
當以上這些都fix之後，在最後關頭，再次被人質疑，delay不能用在mutex held情況下。因為在mutex_enter 的manpage中，有這麼一個注意事項：
QUOTE: Never hold a mutex when calling a service that may block,
for example kmem_alloc(9F) with KM_SLEEP or delay(9F). Sigh!所以這個bug fix到目前為止還沒有結束。
