On Fri, Oct 14, 2011 at 12:57:50PM -0700, Jesse Gross wrote: > On Fri, Oct 14, 2011 at 9:40 AM, Ben Pfaff <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> > --- > >> > 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.
I pushed this version. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
