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 making
get_unaligned_u64() accept all 64-bit unsigned integer types, not just
whichever one happens to be uint64_t. I didn't do the same thing for
put_unaligned_u64() because it is less likely to be a problem in
practice: usually, when userspace writes to kernel data structures it
does so with copies that it knows to be aligned, so that it's not
necessary to use put_unaligned_u64().
This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is
only one reasonable choice of type for each. It won't occur for ovs_be<N>
because OVS always defines those as aliases for the kernel's __be<N> types
when those are available.
This compiled cleanly for me in Scientific Linux 6.0 x86-64.
Reported-by: Pravin Shelar <pshelar@nicira.com>
With this commit, the tree compiles clean with sparse commit 87f4a7fda3d
"Teach 'already_tokenized()' to use the stream name hash table" with patch
"evaluate: Allow sizeof(_Bool) to succeed" available at
http://permalink.gmane.org/gmane.comp.parsers.sparse/2461 applied, as long
as the "include/sparse" directory is included for use by sparse (only),
e.g.:
make CC="CHECK='sparse -I../include/sparse' cgcc"
Both OpenFlow and Netlink contain 64-bit fields that are only guaranteed
to be aligned on 32-bit boundaries. This commit introduces types for
representing these fields and functions for working with them. Followup
commits will make the OpenFlow and Netlink code use these types and
functions.
These accessors are semantically identical to the ones for uint<N>_t data,
but the names are more informative to readers, and the types provide
annotations for sparse.
I had been under the impression that "memcpy" was a valid way to copy
unaligned data into an aligned location for access. But testing on SPARC
has shown that GCC doesn't always honor that intention. It seems that, if
GCC can see that there is a pointer of a type that requires alignment to
a given object, then it will access it directly regardless of whether
memcpy() is used to copy it.
This commit adds a new header with functions to access unaligned data. I
managed to come up with two techniques, one GCC-specific, one generic, that
do avoid the misaligned access in my test case. The GCC-specific technique
is the same one used by the Linux kernel (although no code has been
literally copied). The other one seemed obvious but possibly slow
depending on the compiler's ability to optimize.
The following commit adds a user.
