On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:> Failure to use real-time delay here causes the keyboard to become demonically> possessed in the event of a kernel crash, with wildly blinking lights and> unpredictable behavior. This has resulted in several injuries.

The problem is the normal one when we introduce a new concept into thekernel; there are two kinds of udelay, and they've been conflated. Themost common case is a delay for real hardware devices; this can beeliminated for paravirtualization. The other cases, the tiny minority,are visible delays (keyboard leds), not knowing if they're necessary(very early boot), and async events (other CPUs coming up): ie.everything else.

Is implementation of this distinction worth it? The answer IMHO is no;this is a case where simplicity wins.

Firstly, most modern distributions ship kernels which have almost nodrivers, and modprobe in early boot. So assuming paravirtualizeddrivers, we don't even experience the boot delays.

Secondly, the major delay for my current kernel is IDE probing (3 out of5 seconds of boot time!), but implementing the delay ops in lguest does*nothing* for this, because it uses "msleep()" not "mdelay()". so thecurrent solution isn't sufficient anyway. If this is a real problem forusers I'd rather try to convince the IDE maintainer to use a"real_hardware_mdelay()" or something here.

Cheers!Rusty.PS. lguest doesn't implement the delay functions; I just triedimplemented that now for testing.