Messages in this thread | | | Subject | Re: long long in kernel | From | Jes Sorensen <> | Date | 07 May 1999 18:38:29 +0200 |
| |
>>>>> "Marc" == Marc Unangst <mju@cs.cmu.edu> writes:
Marc> Jes.Sorensen@cern.ch (Jes Sorensen) writes: >> I am curious, what sorta device requires 64 bit entities on a 32 >> bit architecture?
Marc> There are a lot of reasons to want 64-bit quantities in the Marc> kernel -- if you are doing filesystems or I/O work, you Marc> frequently want more than 32 bits to represent a file offset or Marc> object length. Doing math on time values is also a lot easier Marc> if you can store the values as "number of nanoseconds since Marc> [epoch]" rather than as a seconds/nanoseconds pair in a timespec Marc> struct. (A signed 64-bit number can count nanoseconds for 292 Marc> years, which is probably long enough for most purposes; a signed Marc> 32-bit number wraps after about two seconds.)
I am not doubting that there is a need for 64 bit entities within the kernel, I was just asking what types of operations the device in question was needing.
Marc> To port our research code we had to get around this problem, and Marc> ended up just linking libgcc.a into the kernel. It works fine, Marc> and since the Linux kernel depends on gcc in a number of other Marc> places, it doesn't seem to raise the bar any.
Now that sounds plain evil, if you just need 64 bit counters in an efficient way, define a 'count64_t' that is either a u64 on 64 bit archs or two u32's on 32 bit archs and define some macros to operate on this type. This will give you the most efficient code on both 32 bit and 64 bit architectures.
Jes
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |