Jeff: I still do not see your point.
Calls to msec_delay() that you pointed us to resolve to msleep() and NOT mdelay(). In addition we have the advantage of msec_delay() checking the context (in the case the human verification was incorrect). Ganesh. >-----Original Message----- >From: Jeff Garzik [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 25, 2005 9:52 PM >To: Venkatesan, Ganesh >Cc: Chilakala, Mallikarjuna; Ronciak, John; Brandeburg, Jesse; netdev >Subject: Re: PATCH net-drivers-2.6 1/8] e1000: Support for 82571 and 82572 >controllers > >Venkatesan, Ganesh wrote: >> Jeff: >> >> E1000_osdep.h has a macro msec_delay that does exactly what you've >> mentioned below (check for the correct context and call msleep). Did you >> mean that you did not want drivers to have their own msec_delay() >> macros? > >I meant: have a human check the context. In this case, msleep() should >be fine AFAICS, no need for msec_delay(). > >In general, each msec_delay() use is a problem that should be solved. >Any use of mdelay() typically means spinning the kernel for an >inordinate amount of time. You -particularly- want to avoid this >practice when interrupts are disabled, because that locks out interrupts >for several msec. > >Therefore, each msec_delay() should really be an msleep(). In contexts >where a direct msec_delay->msleep conversion is not possible, you should >look at deferred slow path events into a workqueue/kernel thread where >msleep() -is- possible. mdelay() are acceptable, but mainly as a >short-term solution. > > Jeff > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
