[openib-general] Data structure size mismatch

Pradeep Satyanarayana pradeep at us.ibm.com
Mon Nov 14 11:00:14 PST 2005







Roland Dreier <rolandd at cisco.com> wrote on 11/14/2005 07:49:14 AM:

>     Pradeep> I am seeking suggestions with respect to the
>     Pradeep> 32-bit/64-bit issues. Is the macro
>     Pradeep> test_thread_flag(TIF_32BIT), to ascertain if we are in
>     Pradeep> the kernel in the context of a 32-bit app or not, generic
>     Pradeep> enought that it will work across all the 64-bit platforms
>     Pradeep> of interest. It should work for
>     Pradeep> ppc64/sparc64/x86_64/parisc. Is that good enough?
>
> What are you trying to do?  It would be best to make your ABI the same
> for both 32-bit and 64-bit kernels, so no compatibility code is
> required.  Failing that, just hook into the existing compatibility
> support (ie compat_ioctl and friends).

I am trying to use copy_from_user()/copy_to_user of data structures that
contains pointers.

To address the differences in pointer sizes, here are the possible
combinations
that I am trying to address:
user        kernel
32           32 -----> this is simple and copy_*_user() works as expected
64           32 -----> not supported
32           64 -----> compat_ptr functions provide the necessary support.
                       This function takes a compat_ptr_t which is a u32 as
input

64           64 ------> This case still needs to be addressed. One could do
                        a copy_*_user() without using the compat_ptr() if
it is
                        known that this is a 64-bit app.

Unless, there is a guarantee that only 32-bit apps are supported, there is
still
one case that needs to be addressed and that is the last case above. Hence
the need
to ascertain if the invoking app is 32-bit or 64-bit.


>
>     Pradeep> Also, do I use __LP64__ to find out if this is a 64-bit
>     Pradeep> kernel? My research has revealed that this macro will
>     Pradeep> work for gcc versions greater than 3.4.  Now, Sles9sp2
>     Pradeep> uses gcc 3.3.3 and so will not work on Sles9sp2. However,
>     Pradeep> RHEL4U2 uses gcc version 3.4.4. So, even though one may
>     Pradeep> be using the same kernel version, it will work on one
>     Pradeep> distro and not the other. How does one address such
>     Pradeep> issues?
>
> BITS_PER_LONG should be sufficient I think.  But again, what are you
> trying to do?  It would be better to write your code so that it
> doesn't matter whether it is being built for a 32-bit kernel or a
> 64-bit kernel.
>
Ok, this will do nicely. Thanks for pointing it out.

Pradeep
pradeep at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051114/85c18f7c/attachment.html>


More information about the general mailing list