[ovs-dev] [PATCH] dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.

[Jesse Gross]

On Fri, Oct 14, 2011 at 9:40 AM, Ben Pfaff <blp at nicira.com> wrote:
> On Thu, Oct 13, 2011 at 05:13:54PM -0700, Jesse Gross wrote:
>> On Thu, Oct 13, 2011 at 9:53 AM, Ben Pfaff <blp at nicira.com> wrote:
>> > Unix 64-bit ABIs have two 64-bit types: "long" and "long long". ??Either of
>> > these is a reasonable choice for uint64_t (the userspace type) and for
>> > __u64 (the kernel type). ??Unfortunately, kernel and userspace don't
>> > necessarily agree on the choice, and in fact the choice varies across
>> > kernel versions and architectures.
>> >
>> > Now that OVS is actually using kernel types in its kernel header, this
>> > can make a difference: when __u64 and uint64_t differ, passing a pointer
>> > to __u64 to OVS function get_unaligned_u64() yields a compiler warning
>> > or error.
>> >
>> > This commit fixes up the problems of this type found in OVS, by avoiding
>> > calls to get_unaligned_u64() on these types.
>> >
>> > I suspect that this problem will recur in the future. ??I'm open to
>> > suggestions on how we can making "uint64_t *" and "__u64 *" always
>> > incompatible from the viewpoint of sparse.
>> >
>> > Reported-by: Pravin Shelar <pshelar at nicira.com>
>> > ---
>> > Another solution would be to make get_unaligned_u64() accept both
>> > types with some kind of macro, like this:
>> >
>> > #define get_unaligned_u64(p) \
>> > ?? ?? ?? ??(BUILD_ASSERT(sizeof *(p) == 8), \
>> > ?? ?? ?? ?? sizeof (*(p) % 1), \
>> > ?? ?? ?? ?? get_unaligned_u64__((const uint64_t *) (p)))
>>
>> I think you probably could convince sparse to complain by declaring a
>> type with __attribute__((address_space(XXX))) but it seems like more
>> mess than it is worth.
>>
>> I think this can only occur with things that should be using
>> get_unaligned_u64(), right?  In that case, the macro magic that you
>> have above seems like a more comprehensive and self contained
>> solution.  To me, that makes it a pretty significant improvement.
>
> OK, here's v2:

Looks good, thanks.