>> The question then becomes: Use "long long" or not?
>
>> All platforms can do 64-bit calculations via "long long", with
>> the compiler emulating as needed. Older versions of gcc could be
>> slow, but this problem has been fixed.
>
> It's not a gcc problem, but a general dislike of non-native integer
Sure it is a gcc problem. We get a few choices:
x. Find a way to avoid big numbers. For example, sector or page numbers
in place of byte offsets. Well, this whole patch is because people
want better than 1-second resolution.
y. Do the math with lots of gross code to deal with integers that
are larger than the native types. On some older versions of gcc,
this is faster than...
z. Let gcc handle the problem. This works with all allowed compilers,
but older versions produce slow code. For recent compilers, this
method is second only to option x, which doesn't work here.
> formats by the kernel developers. Personally, I've nothing against it
> at all, but I've seen several patches rejected simply because they
> used long long on 32-bit platforms.
I'll try to remember:
The jiffies counter is performance-critical, and the existing 495-day
limit is good enough for nearly everyone.
Some of the filesystem code is also performance-critical, and it is
often OK to use sector or page numbers instead of byte offsets.
We will be going to 64-bit values in a few places AFAIK.
Anything else? In both cases above, "way to avoid..." was chosen.
That is a wonderful option when it works.
>> Even though I have an old gcc, I'd prefer letting the compiler
>> handle the job. Using "long long" would make the code more
>> maintainable. Somebody actually using this new feature will need
>> a new libc anyway, and I think libc now requires the newer
>> compiler.
>
> Remember that libc can't be used in the kernel itself...
Yes, but the logic goes like this:
If you have an old gcc, you can not compile a new libc.
If you can not compile a new libc, you can not use these calls.
If you can not use these calls, you won't care how slow they are.
-
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/