Re: long long in kernel

Jes Sorensen (Jes.Sorensen@cern.ch)
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/