Re: [PATCH] Implement prctl(PR_GET_ENDIAN) for all architectures

[Helge Deller]

On 11/09/2009 10:32 PM, Mikael Pettersson wrote:
> Andrew Morton writes:
>   >  On Thu, 22 Oct 2009 21:35:33 +0200
>   >  Helge Deller<deller@xxxxxx>  wrote:
>   >
>   >  >  The PR_GET_ENDIAN and PR_SET_ENDIAN prctl() calls have been implemented
>   >  >  to allow to switch processes at runtime from big-endian to little-endian
>   >  >  mode (and vice versa) on PowerPC processors. Since the other architectures
>   >  >  don't support this feature, they currently will just fail and return -EINVAL.
>   >  >
>   >  >  This patch adds just minimal overhead and implements the PR_GET_ENDIAN
>   >  >  call for all other architectures by returning the native endianess of
>   >  >  the architecture. Furthermore, calling prctl(PR_SET_ENDIAN) with the
>   >  >  native endianess of the architecture will succeed, while trying to
>   >  >  set another (not-supported) endianess, will fail.
>   >  >
>   >  >  The patch can be tested with the following program:
>   >  >
>   >  >  #include<stdio.h>
>   >  >  #include<linux/prctl.h>
>   >  >
>   >  >  int main(int argc, char **argv)
>   >  >  {
>   >  >  	int endian, ret;
>   >  >
>   >  >  	ret = prctl(PR_GET_ENDIAN,&endian);
>   >  >  	if (ret)
>   >  >  		perror("prctl(PR_GET_ENDIAN) not implemented");
>   >  >  	printf("current process/machine is running in %s endian mode (%d)\n",
>   >  >  		endian == PR_ENDIAN_LITTLE ? "little":"big", endian);
>   >  >
>   >  >  	/* setting native endianess should succeed */
>   >  >  	ret = prctl(PR_SET_ENDIAN, endian);
>   >  >  	printf("prctl(PR_SET_ENDIAN,%d) should succeed: %s\n",
>   >  >  		endian, ret == 0 ? "OK":"FAIL");
>   >  >
>   >  >  	/* setting foreign endianess should fail */
>   >  >  	endian = (endian == PR_ENDIAN_LITTLE) ?
>   >  >  		PR_ENDIAN_BIG : PR_ENDIAN_LITTLE;
>   >  >  	ret = prctl(PR_SET_ENDIAN, endian);
>   >  >  	printf("prctl(PR_SET_ENDIAN,%d) should fail: %s\n",
>   >  >  		endian, ret == 0 ? "OK":"FAIL");
>   >  >  }
>   >  >
>   >
>   >  The changelog forgot to provide any reason for making this change to
>   >  the kernel.
>
> Why is PR_GET_ENDIAN needed? Surely user-space can detect the current
> endianess for itself?

PR_GET_ENDIAN/PR_SET_ENDIAN was introduced with:
commit 651d765d0b2c72d33430487c8b6ef64c60cd2134
Author: Anton Blanchard <anton@xxxxxxxxx>
Date:   Wed Jun 7 16:10:19 2006 +1000

    [PATCH] Add a prctl to change the endianness of a process.

    This new prctl is intended for changing the execution mode of the
    processor, on processors that support both a little-endian mode and a
    big-endian mode.  It is intended for use by programs such as
    instruction set emulators (for example an x86 emulator on PowerPC),
    which may find it convenient to use the processor in an alternate
    endianness mode when executing translated instructions.

    Note that this does not imply the existence of a fully-fledged ABI for
    both endiannesses, or of compatibility code for converting system
    calls done in the non-native endianness mode.  The program is expected
    to arrange for all of its system call arguments to be presented in the
    native endianness.

    Switching between big and little-endian mode will require some care in
    constructing the instruction sequence for the switch.  Generally the
    instructions up to the instruction that invokes the prctl system call
    will have to be in the old endianness, and subsequent instructions
    will have to be in the new endianness.

    Signed-off-by: Anton Blanchard <anton@xxxxxxxxx>
    Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx>

> Also, which endianess does this refer to? ARM has had and continues to
> invent bizarre endianess rules, where the endianess of some datum depends
> not only on the endianess flag in a core control register but also the
> functional unit operating on the data and the ARM ISA version. Some of
> these endianess properties are unchangeable, some may be changeable in
> specific implementations.
>
> What about archs that always run in one endianess but support other-endian
> data accesses via special instruction operands? (I believe SPARC falls into
> this category.) PR_SET_ENDIAN on the other-endian value must fail, but what
> does that mean to the program? That it can't do other-endian accesses? No.

Right. I think no one objects on what you are writing here.
 
> I think the very concept of flipping a thread-global endianess mode flag
> is too architecture specific to be treated as a generic thing.

Please read my patch again.
It's not trying to flip any endianess settings in any generic way at all.
For PR_GET_ENDIAN it just returns the real kernels endianess instead of -EINVAL,
and it does not allow you to change the endianess with PR_SET_ENDIAN.

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/