[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0711191734270.32296@gandalf.stny.rr.com>
Date: Mon, 19 Nov 2007 17:36:39 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: Bastian Blank <bastian@...di.eu.org>
cc: Glauber de Oliveira Costa <gcosta@...hat.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
glommer@...il.com, tglx@...utronix.de, mingo@...e.hu,
rusty@...tcorp.com.au, ak@...e.de, chrisw@...s-sol.org,
avi@...ranet.com, anthony@...emonkey.ws,
virtualization@...ts.linux-foundation.org, lguest@...abs.org,
kvm-devel@...ts.sourceforge.net, zach@...are.com,
jun.nakajima@...el.com
Subject: Re: [PATCH 7/24] consolidate msr.h
On Mon, 19 Nov 2007, Bastian Blank wrote:
> On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote:
> > - wrmsrl(MSR_CSTAR, ia32_cstar_target);
> > + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target);
>
> Hmm, why do you add explicit casts? The compiler should convert that
> correctly on its own.
>
> > +static inline void wrmsrl(unsigned int msr, unsigned long long val)
>
> Hmm, long long is 64 bit on all x86, but why not use explicit u64 to
> show that?
(quick reply)
With PVOPS on it gives compiler warnings without that explict cast.
Without looking at the code, IIRC with non-PVOPS it is a macro directly
into asm, so it didn't matter what the cast was. But with PVOPS as a
function, it gave compiler warnings.
Take it out and try compiling it for both i386 and x86_64. One of them
gave warnings. But maybe it's not a problem now.
-- Steve
-
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