[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071120055113.GC20436@elte.hu>
Date: Tue, 20 Nov 2007 06:51:13 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Bastian Blank <bastian@...di.eu.org>,
Glauber de Oliveira Costa <gcosta@...hat.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
glommer@...il.com, tglx@...utronix.de, 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
* Steven Rostedt <rostedt@...dmis.org> 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.
i dont think there's ever any true need (and good cause) to force
integer type casts like that at the callee site.
Ingo
-
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