linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Tonnerre <tonnerre@thundrix.ch>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Add sparse "__iomem" infrastructure to check PCI address usage
Date: Mon, 13 Sep 2004 11:48:56 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0409131142370.2378@ppc970.osdl.org> (raw)
In-Reply-To: <20040913183126.GA19399@thundrix.ch>



On Mon, 13 Sep 2004, Tonnerre wrote:
> 
> On Sun, Sep 12, 2004 at 08:00:48PM -0700, Linus Torvalds wrote:
> > Generally, you shouldn't ever use __force in a driver or anything like 
> > that.
> 
> Why don't we send the __force attribute into some #ifdef that is never
> defined unless  you're in  arch specific code?  This way  we'd prevent
> stupid people from doing stupid things.

Hey, the thing is, that may well prevent smart people from doing smart 
things too. Give 'em rope, within reason.

The point behind __force is not so much that you should never use it, but 
that you should never use it by _mistake_. It's very easy (and often 
_required_) to have a regular typecast in C, and it can often hide bugs 
when you cast something in a way that you didn't really think through.

For example, we often have generic "void *" or "unsigned long" things that
are used for passing opaque data around, and they need casts when working
with them. It is quite conceivable that you need an address space cast
too, and that you need to use "__force" to do so. It might be ok, even in
a driver. But hopefully it's something where the action of having to force 
the cast makes people think about it more. And the fact that there 
probably never will be very _man_ casts like that means that they'll stand 
out.

If people start using "__force" to hide their own bugs, we'll just have to 
start stringing them up. Hang'em high, I say. But maybe somebody has a 
valid reason at times.

		Linus

  reply	other threads:[~2004-09-13 18:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200409110726.i8B7QTGn009468@hera.kernel.org>
2004-09-13  0:26 ` Add sparse "__iomem" infrastructure to check PCI address usage Jeff Garzik
2004-09-13  0:50   ` David S. Miller
2004-09-13  2:31   ` Linus Torvalds
2004-09-13  2:41     ` Jeff Garzik
2004-09-13  3:00       ` Linus Torvalds
2004-09-13 14:22         ` Geert Uytterhoeven
2004-09-13 14:33           ` Linus Torvalds
2004-09-13 18:31         ` Tonnerre
2004-09-13 18:48           ` Linus Torvalds [this message]
2004-09-13 18:51           ` viro

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=Pine.LNX.4.58.0409131142370.2378@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tonnerre@thundrix.ch \
    /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;
as well as URLs for NNTP newsgroup(s).