public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jpranevich@lycos-inc.com, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com
Subject: Re: linux-2.2.18-pre19 asm/delay.h problem?
Date: Wed, 22 Nov 2000 10:57:53 +0100 (MET)	[thread overview]
Message-ID: <200011220957.KAA26634@cave.bitwizard.nl> (raw)
In-Reply-To: <E13yNHb-0005O4-00@the-village.bc.nu> from Alan Cox at "Nov 21, 2000 11:57:02 pm"

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. 

-- 
** R.E.Wolff@BitWizard.nl ** 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. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-11-22 10:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-21 23:51 linux-2.2.18-pre19 asm/delay.h problem? jpranevich
2000-11-21 23:57 ` Alan Cox
2000-11-22  2:16   ` Peter Samuelson
2000-11-22  9:57   ` Rogier Wolff [this message]
2000-11-22 15:48     ` Pauline Middelink
2000-11-22 17:04       ` Igmar Palsenberg
2000-11-22 16:49         ` Andreas Schwab
2000-11-22 23:43           ` Igmar Palsenberg
2000-11-22 22:52             ` Alan Cox
2000-11-23 10:10               ` David Woodhouse
2000-11-24 17:15               ` Oliver Xymoron
2000-11-24 17:41                 ` Jeff Epler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200011220957.KAA26634@cave.bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jpranevich@lycos-inc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox