lkml.org 
[lkml]   [2009]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for more than 2.15 seconds

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.

For this specific case using long long should be fine. Even if there is
a case where long long is not 64bits, then this would not break
functionality, simply increase of decrease the dynamic range of
max_delta_ns and min_delta_ns.

Cheers
Jon

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0807.2/2805.html




\
 
 \ /
  Last update: 2009-04-22 19:07    [W:0.215 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site