2000-11-22 00:23:08

by jpranevich

[permalink] [raw]
Subject: linux-2.2.18-pre19 asm/delay.h problem?



Hello,

Possibly an issue with an external module that I'm using, but when I compile a
module that is pulling the definition of udelay() from asm/delay.h, it's
referencing __bad_udelay(). However, I can't seem to find the __bad_udelay()
function actually defined anyplace. (Although it could be somewhere in the
kernel source that my grep missed.)

Would this be a bug in the module that I'm compiling? Or a real forgotten and
unused symbol in the delay.h file? I doubt it would be the latter, but I can't
figure out what I should link this module against to make things work.

Thanks so much,

Joe Pranevich
Product Support Analyst
Lycos.com



2000-11-22 00:27:00

by Alan Cox

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

> module that is pulling the definition of udelay() from asm/delay.h, it's
> referencing __bad_udelay(). However, I can't seem to find the __bad_udelay()
> function actually defined anyplace. (Although it could be somewhere in the
> kernel source that my grep missed.)

Its intentionally missing

> Would this be a bug in the module that I'm compiling? Or a real forgotten and

You got it. The module is doing an overlarge delay

2000-11-22 02:46:54

by Peter Samuelson

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?


[Alan Cox]
> You got it. The module is doing an overlarge delay

Perhaps people would stop asking this question if the symbol were
renamed from __bad_udelay() to, say, __use_mdelay_instead_please().

Sort of like the DNS zone (somewhere at UCLA was it?) where they had
something like 'quit 86400 IN CNAME use.exit.to.get.out.of.nslookup.'

Peter

2000-11-22 10:28:22

by Rogier Wolff

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

Alan Cox wrote:
> > module that is pulling the definition of udelay() from asm/delay.h, it's
> > referencing __bad_udelay(). However, I can't seem to find the __bad_udelay()
> > function actually defined anyplace. (Although it could be somewhere in the
> > kernel source that my grep missed.)
>
> Its intentionally missing

Alan, Linus,

Would it be an idea to define __bad_udelay() somewhere? (No don't stop
reading!) ....

.... Inside a #if 0. This question keeps on popping up, and people
seem to be able to grep for definitions of stuff well enough. Then
near the definition you can explain this. It's a form of documenting
this "trick"...

#if 0
/* Note: This definition is not for real. The idea about __bad_udelay is
that you get a compile-time error if you call udelay with a number of
microseconds that is too large for udelay. There is mdelay if you need
delays on the order of miliseconds. Please update the places where
udelay is called with this large constant!

If you change the #if 0 to #if 1, the stuff you're trying to compile will
compile, but you'll crash your system when it's used.
*/

#define __bad_udelay() panic("Udelay called with too large a constant")
#endif


Roger.

--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.

2000-11-22 16:18:58

by Pauline Middelink

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

On Wed, 22 Nov 2000 around 10:57:53 +0100, Rogier Wolff wrote:
[skip]

> .... Inside a #if 0. This question keeps on popping up, and people
> seem to be able to grep for definitions of stuff well enough. Then
> near the definition you can explain this. It's a form of documenting
> this "trick"...
>
> #if 0
> /* Note: This definition is not for real. The idea about __bad_udelay is
> that you get a compile-time error if you call udelay with a number of
> microseconds that is too large for udelay. There is mdelay if you need
> delays on the order of miliseconds. Please update the places where
> udelay is called with this large constant!
>
> If you change the #if 0 to #if 1, the stuff you're trying to compile will
> compile, but you'll crash your system when it's used.
> */
>
> #define __bad_udelay() panic("Udelay called with too large a constant")
> #endif

I want to bed that somebody will post a "fix" which will patch
the #if 0 to 1. :)

Met vriendelijke groet,
Pauline Middelink
--
PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0 58 A3 06 9D B6 34 39 E2
For more details look at my website http://www.polyware.nl/~middelink

2000-11-22 16:27:19

by Igmar Palsenberg

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?


> > #define __bad_udelay() panic("Udelay called with too large a constant")

Can't we change that to :
#error "Udelay..."


Igmar

2000-11-22 17:19:41

by Andreas Schwab

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

Igmar Palsenberg <[email protected]> writes:

|> > > #define __bad_udelay() panic("Udelay called with too large a constant")
|>
|> Can't we change that to :
|> #error "Udelay..."

No.

Andreas.

--
Andreas Schwab "And now for something
SuSE Labs completely different."
[email protected]
SuSE GmbH, Schanz?ckerstr. 10, D-90443 N?rnberg

2000-11-22 23:05:51

by Igmar Palsenberg

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?


> |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> |>
> |> Can't we change that to :
> |> #error "Udelay..."
>
> No.

?? I think I'm missing something here.


> Andreas.


Igmar

2000-11-22 23:22:42

by Alan Cox

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

> > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > |>
> > |> Can't we change that to :
> > |> #error "Udelay..."
> >
> > No.
>
> ?? I think I'm missing something here.

preprocessor stuff is done too early for this

2000-11-23 10:41:06

by David Woodhouse

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?


[email protected] said:
> > |> Can't we change that to :
> > |> #error "Udelay..."
> >
> > No.
>
> ?? I think I'm missing something here.
> preprocessor stuff is done too early for this

We were talking about

#if 0
/* Don't turn this on, fix your code instead */

void __bad_udelay(int c)
{
#error you broke it. read the damn comment
}
#endif

... so that when people search the tree for __bad_udelay they find this,
and if they're silly enough to change the 0 to a 1 then it'll still break.

--
dwmw2


2000-11-24 17:46:34

by Oliver Xymoron

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

On Wed, 22 Nov 2000, Alan Cox wrote:

> > > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > > |>
> > > |> Can't we change that to :
> > > |> #error "Udelay..."
> > >
> > > No.
> >
> > ?? I think I'm missing something here.
>
> preprocessor stuff is done too early for this

You could still change it to
__bug__module_is_using_a_delay_thats_too_large__please_report()..

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

2000-11-24 18:12:04

by Jeff Epler

[permalink] [raw]
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?

On Fri, Nov 24, 2000 at 11:15:50AM -0600, Oliver Xymoron wrote:
> You could still change it to
> __bug__module_is_using_a_delay_thats_too_large__please_report()..

I thought that's where we started?

Can we somehow use the GNU linker trick which permits a warning about e.g.
gets at link time? (Is it even documented somewhere?) Something like:

/* bad_udelay.c */
static char bad_udelay_warning[] __attribute__((__section__(".gnu.warning")))
= "warning: constant udelay too long";
bad_udelay() { BUG(); }

Jeff