linux-kernel - Re: [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for more than 2.15 seconds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10f740e80904221153g5cb23756p2f71abe44f4273f3@mail.gmail.com>
Date:	Wed, 22 Apr 2009 20:53:44 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Jon Hunter <jon-hunter@...com>
Cc:	Chris Friesen <cfriesen@...tel.com>,
	john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for 
	more than 2.15 seconds

On Wed, Apr 22, 2009 at 19:04, Jon Hunter <jon-hunter@...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@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/