[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185270544.5439.252.camel@localhost.localdomain>
Date: Tue, 24 Jul 2007 19:49:03 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Satyam Sharma <ssatyam@....iitk.ac.in>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Howells <dhowells@...hat.com>,
Nick Piggin <nickpiggin@...oo.com.au>, Andi Kleen <ak@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 4/8] i386: bitops: Kill volatile-casting of memory
addresses
> The "const volatile" is so that you can pass an arbitrary pointer. The
> only kind of abritraty pointer is "const volatile".
>
> In other words, the "volatile" has nothing at all to do with whether the
> memory is volatile or not (the same way "const" has nothing to do with it:
> it's purely a C type *safety* issue, exactly the same way "const" is a
> type safety issue.
>
> A "const" on a pointer doesn't mean that the thing it points to cannot
> change. When you pass a source pointer to "strlen()", it doesn't have to
> be constant. But "strlen()" takes a "const" pointer, because it work son
> constant pointers *too*.
However... What about that:
- This "volatile" will allow to pass pointers to volatile data to the
bitops.
- Most users of "volatile" in the kenrel (except maybe jiffies) are
bogus
- Thus let's remove it -as a type safety thing- to catch more of those
stupid volatile that shouldn't be ? :-)
Besides, as Nick pointed out, it prevents some valid optimizations.
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists