From: Jeff D. <jd...@ad...> - 2006-10-18 18:58:13
|
On Wed, Oct 18, 2006 at 01:39:55AM +0200, Blaisorblade wrote: > Jeff, I remember vaguely a recent (>=2.6.17) patch about udelay fixing a > misbehaviour, would you please complete my recollection and verify the > interaction with this? There were two problems. One was that the declaration and definition of most arch __const_udelay were mismatched. It was simply a name mismatch, would not cause miscompilation, but did cause conceptual problems: arch/i386/lib/delay.c: inline void __const_udelay(unsigned long xloops) include/asm-i386/delay.h: extern void __const_udelay(unsigned long usecs); I'm also somewhat interested in how something that's defined inline in a C file will be accessible to other files such that an extern declaration would be needed. The second problem (IIRC) was the mismatch you noted, although I can't find that part of the patch any more. I didn't understand the magic constants in asm-i386/delay.h, and didn't see the comments in arch/i386/lib/delay.c, which might have helped. > This bug is here at least since 2.6.16. > Suggested solution: > 1) have _our own_ delay.h, to avoid depending on subarchs' changes > 2) first avoid playing so complex tricks, then maybe copy their > implementation (note it is slightly different already among x86 and > x86_64). This sounds reasonable. Jeff |