archive mirror
 help / color / mirror / Atom feed
From: David Howells <>
To: "Richard B. Johnson" <>
Cc: David Woodhouse <>,
	Dinesh Gandhewar <>,
Subject: Re: volatile variable
Date: Mon, 11 Aug 2003 15:40:45 +0100	[thread overview]
Message-ID: <30059.1060612845@warthog.warthog> (raw)
In-Reply-To: Message from "Richard B. Johnson" <>  of "Mon, 11 Aug 2003 10:06:36 EDT." <Pine.LNX.4.53.0308110944350.17240@chaos>

> > Just in case there are people reading this who don't realise that
> > Richard is trolling -- do not ever use sleep_on() and friends. They
> > _will_ introduce bugs, and hence they _will_ be removed from the kernel
> > some time in the (hopefully not-so-distant) future.
> >

That's an excellent idea:-) It'd also be nice to sort out all the
interruptible vs non-interruptible problems previously discussed.

> The linux-2.4.20 contains 516 references to "sleep_on" in the
> `drivers` tree. This is hardly a function or macro that will
> be removed.

That doesn't mean it won't be either - maybe in 2.7.

> Any driver that makes its own 'sleep until' function is fundamentally
> broken.

Yes... they should call schedule() in the correct way to avoid races.

> If course, older drivers do 'know' about schedule(), but that doesn't make
> them correct.

That doesn't make them incorrect, either.

> Again, this is incorrect. If you look at the declaration of schedule(),
> you will note "asmlinkage void schedule(void);". Now look up
> "asmlinkage"
> #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))

That's just because schedule() needs to be called from assembly
(entry.S). This merely nails the ABI in place for those functions that need to
be called from assembly code, so that if someone decides they want to tell the
C compiler to use more or less registers for argument passing, then they don't
have to fix up all the .S files too.

> The regparm(0) atttibute tells gcc that schedule() will get any/all
> of its parameters in registers.

No it doesn't. It says schedule() will get zero arguments in registers (on the
i386 arch anyway). It does, however, mean that EAX, EDX and ECX will all be
clobbered - probably.

> Since schedule() receives no parameters, that means that, as far as gcc is
> concerned, it cannot modify anything.

No it doesn't. It just means schedule() takes no parameters.


  parent reply	other threads:[~2003-08-11 14:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-01 10:57 volatile variable Dinesh  Gandhewar
2003-08-01 11:38 ` Richard B. Johnson
2003-08-11 13:33   ` David Woodhouse
2003-08-11 14:06     ` Richard B. Johnson
2003-08-11 14:37       ` Jakub Jelinek
2003-08-11 14:38       ` David Woodhouse
2003-08-11 14:40       ` David Howells [this message]
2003-08-11 14:49       ` Mike Galbraith
2003-08-11 17:07       ` Robert Love
2003-08-02 14:52 Harm Verhagen

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:

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

  git send-email \
    --in-reply-to=30059.1060612845@warthog.warthog \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).