Displaying 3 results from an estimated 3 matches for "atomic_long_".
Did you mean:
atomic_long_t
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
...t use u64 types.
>> > If they're not reliant on manipulating 64-bit quantities, then what's
>> > the point of calling them atomic _64_.
>>
>> I haven't checked all architectures, but I assume what happens is that
>> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
>> to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from...
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
...t use u64 types.
>> > If they're not reliant on manipulating 64-bit quantities, then what's
>> > the point of calling them atomic _64_.
>>
>> I haven't checked all architectures, but I assume what happens is that
>> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
>> to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from...
2015 Oct 19
0
[PATCH] drm/virtio: use %llu format string form atomic64_t
...Regarding your question of
> Instead of sprinkling casts, is there any good reason why atomic64_read()
> and atomic64_t aren't "long long" everywhere, cfr. u64?
I assume the answer is that some (all?) 64-bit architectures intentionally
return 'long' here, in order for atomic_long_read() to return 'long' on
all architectures, given the definitions from
include/asm-generic/atomic-long.h
We would have to either change those, or we have to pick between
atomic_long_* or atomic64_* to have a consistent return type.
Arnd