DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=xOfskEDCeJi4GIfXjhy/hODQwCJefVct9eU1fEhZfUF+Ti41B8aAssK/3PNOsKdpu4
         248NMF5VlPd9W6RmOjCYvID5M3RdYcgeKyJoG5j+J5+ziDtlVeg3oOOtcvrS6HVzmp+J
         hlTMuLUteBY/wWgnrtqvKGMbqqcmEaH5jHnTY=
MIME-Version: 1.0
In-Reply-To: <49EF4E14.6090708@ti.com>
References: <49ECE615.2010800@ti.com> <20090421063523.GA8020@elte.hu>
	 <1240345936.6080.6.camel@localhost> <49EE54B4.9020700@ti.com>
	 <1240358715.6080.42.camel@localhost> <49EE89EF.1000707@ti.com>
	 <49EF37FC.8020909@nortel.com> <49EF4E14.6090708@ti.com>
Date: Wed, 22 Apr 2009 20:53:44 +0200
Message-ID: <10f740e80904221153g5cb23756p2f71abe44f4273f3@mail.gmail.com>
Subject: Re: [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for 
	more than 2.15 seconds
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Chris Friesen <cfriesen@nortel.com>, john stultz <johnstul@us.ibm.com>,
       Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
       "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1958
Lines: 44

On Wed, Apr 22, 2009 at 19:04, Jon Hunter <jon-hunter@ti.com> wrote:
> Chris Friesen wrote:
>>
>> Isn't "long long" guaranteed to be 64-bit on all linux systems?
>
> If long long is guaranteed to be 64-bits this is the way to go. Looks like
> there was some previous discussion on making u64 always a long long, but I
> am not sure that this happened [1]. So may be this does confirm this?
>
>> Unless the width is critical, I'd prefer to stay away from u64 until it
>> gets unified between architectures.  I recently ran into a problem
>> printk-ing a "u64" value because it was a different type on ppc64 than
>> x86-64.
>
> It is not critical but maybe more ideal, as it would be nice to be explicit
> that this variable is intended to be 64bits. In fact the issue you saw with
> the printk is one of the reasons that I previously mentioned of why I had
> opted to stay with long long. I also found that this issue was discussed in
> the thread I mentioned above [1]. Seems like a common problem.
>
> The alternative is to use u64 and make sure that all printks cast the
> variable to long long where necessary. However, this is not clean and you do
> run the risk of a new print being added that does not take this into account
> and breaks the code for some architectures. So I wished to avoid this.

That's why recently, u64 became `unsigned long long' on ppc64. So please stay
away from the casts.

-- 
Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/