linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
@ 2017-01-28 11:13 Helge Deller
  2017-02-01  0:26 ` Andrew Morton
  0 siblings, 1 reply; 9+ messages in thread
From: Helge Deller @ 2017-01-28 11:13 UTC (permalink / raw)
  To: linux-kernel, Andrew Morton; +Cc: linux-parisc

The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
implemented for PowerPC only.
This trivial patch adds support for this syscall for all other architectures.

Signed-off-by: Helge Deller <deller@gmx.de>

diff --git a/kernel/sys.c b/kernel/sys.c
index 842914e..5818e5e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -79,9 +79,6 @@
 #ifndef GET_FPEXC_CTL
 # define GET_FPEXC_CTL(a, b)	(-EINVAL)
 #endif
-#ifndef GET_ENDIAN
-# define GET_ENDIAN(a, b)	(-EINVAL)
-#endif
 #ifndef SET_ENDIAN
 # define SET_ENDIAN(a, b)	(-EINVAL)
 #endif
@@ -2136,7 +2133,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 			return -EFAULT;
 		break;
 	case PR_GET_ENDIAN:
+#ifdef GET_ENDIAN
 		error = GET_ENDIAN(me, arg2);
+#elif defined(__BIG_ENDIAN)
+		error = put_user(PR_ENDIAN_BIG, (unsigned int __user *)arg2);
+#else
+		error = put_user(PR_ENDIAN_LITTLE, (unsigned int __user *)arg2);
+#endif
 		break;
 	case PR_SET_ENDIAN:
 		error = SET_ENDIAN(me, arg2);

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-01-28 11:13 [PATCH] prctl: implement PR_GET_ENDIAN for all architectures Helge Deller
@ 2017-02-01  0:26 ` Andrew Morton
  2017-02-01 19:47   ` Helge Deller
  2017-02-01 23:12   ` James Bottomley
  0 siblings, 2 replies; 9+ messages in thread
From: Andrew Morton @ 2017-02-01  0:26 UTC (permalink / raw)
  To: Helge Deller; +Cc: linux-kernel, linux-parisc, Michael Kerrisk, linux-api

On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de> wrote:

> The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
> implemented for PowerPC only.
> This trivial patch adds support for this syscall for all other architectures.

Seems reasonable.  I guess.  Why is this needed?

The man page will need updating.  It says "PowerPC only".

> 
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 842914e..5818e5e 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -79,9 +79,6 @@
>  #ifndef GET_FPEXC_CTL
>  # define GET_FPEXC_CTL(a, b)	(-EINVAL)
>  #endif
> -#ifndef GET_ENDIAN
> -# define GET_ENDIAN(a, b)	(-EINVAL)
> -#endif
>  #ifndef SET_ENDIAN
>  # define SET_ENDIAN(a, b)	(-EINVAL)
>  #endif
> @@ -2136,7 +2133,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>  			return -EFAULT;
>  		break;
>  	case PR_GET_ENDIAN:
> +#ifdef GET_ENDIAN
>  		error = GET_ENDIAN(me, arg2);
> +#elif defined(__BIG_ENDIAN)
> +		error = put_user(PR_ENDIAN_BIG, (unsigned int __user *)arg2);
> +#else
> +		error = put_user(PR_ENDIAN_LITTLE, (unsigned int __user *)arg2);
> +#endif
>  		break;
>  	case PR_SET_ENDIAN:
>  		error = SET_ENDIAN(me, arg2);

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-01  0:26 ` Andrew Morton
@ 2017-02-01 19:47   ` Helge Deller
  2017-02-01 22:03     ` Andrew Morton
  2017-02-01 23:12   ` James Bottomley
  1 sibling, 1 reply; 9+ messages in thread
From: Helge Deller @ 2017-02-01 19:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-parisc, Michael Kerrisk, linux-api

Hi Andrew,

On 01.02.2017 01:26, Andrew Morton wrote:
> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de> wrote:
> 
>> The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> implemented for PowerPC only.
>> This trivial patch adds support for this syscall for all other architectures.
> 
> Seems reasonable.  I guess.

Heck, I did forgot but I submitted a similar patch 8 years ago:
http://www.serverphorums.com/read.php?12,51902

> Why is this needed?

It's not actually needed beside the trivial reason of providing an interface
not just for one single architecture.

After reading the discussion from 2009 again, I'm fine if 
you would simply drop the patch. The decision up to you.

> The man page will need updating.  It says "PowerPC only".

In case you would include the patch I'd send patches to update
the manpage.

Thanks,
Helge

>> diff --git a/kernel/sys.c b/kernel/sys.c
>> index 842914e..5818e5e 100644
>> --- a/kernel/sys.c
>> +++ b/kernel/sys.c
>> @@ -79,9 +79,6 @@
>>  #ifndef GET_FPEXC_CTL
>>  # define GET_FPEXC_CTL(a, b)	(-EINVAL)
>>  #endif
>> -#ifndef GET_ENDIAN
>> -# define GET_ENDIAN(a, b)	(-EINVAL)
>> -#endif
>>  #ifndef SET_ENDIAN
>>  # define SET_ENDIAN(a, b)	(-EINVAL)
>>  #endif
>> @@ -2136,7 +2133,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>>  			return -EFAULT;
>>  		break;
>>  	case PR_GET_ENDIAN:
>> +#ifdef GET_ENDIAN
>>  		error = GET_ENDIAN(me, arg2);
>> +#elif defined(__BIG_ENDIAN)
>> +		error = put_user(PR_ENDIAN_BIG, (unsigned int __user *)arg2);
>> +#else
>> +		error = put_user(PR_ENDIAN_LITTLE, (unsigned int __user *)arg2);
>> +#endif
>>  		break;
>>  	case PR_SET_ENDIAN:
>>  		error = SET_ENDIAN(me, arg2);

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-01 19:47   ` Helge Deller
@ 2017-02-01 22:03     ` Andrew Morton
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Morton @ 2017-02-01 22:03 UTC (permalink / raw)
  To: Helge Deller; +Cc: linux-kernel, linux-parisc, Michael Kerrisk, linux-api

On Wed, 1 Feb 2017 20:47:06 +0100 Helge Deller <deller@gmx.de> wrote:

> Hi Andrew,
> 
> On 01.02.2017 01:26, Andrew Morton wrote:
> > On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de> wrote:
> > 
> >> The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
> >> implemented for PowerPC only.
> >> This trivial patch adds support for this syscall for all other architectures.
> > 
> > Seems reasonable.  I guess.
> 
> Heck, I did forgot but I submitted a similar patch 8 years ago:
> http://www.serverphorums.com/read.php?12,51902
> 
> > Why is this needed?
> 
> It's not actually needed beside the trivial reason of providing an interface
> not just for one single architecture.
> 
> After reading the discussion from 2009 again, I'm fine if 
> you would simply drop the patch. The decision up to you.

Can't decide.  I guess that moving it into the kernel will, over time,
eliminate some irritating ifdefs from userspace code.

The implementation itself is a bit half-assed.  The put_user() in
arch/powerpc/kernel/process.c:get_endian() should be moved into
kernel/sys.c.  So the arch code only does the "what endianness am I"
function and common code copies that out to userspace.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-01  0:26 ` Andrew Morton
  2017-02-01 19:47   ` Helge Deller
@ 2017-02-01 23:12   ` James Bottomley
  2017-02-02  5:08     ` Andy Lutomirski
  2017-02-05 11:48     ` Matt Turner
  1 sibling, 2 replies; 9+ messages in thread
From: James Bottomley @ 2017-02-01 23:12 UTC (permalink / raw)
  To: Andrew Morton, Helge Deller
  Cc: linux-kernel, linux-parisc, Michael Kerrisk, linux-api

On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de>
> wrote:
> 
> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
> > implemented for PowerPC only. This trivial patch adds support for 
> > this syscall for all other architectures.
> 
> Seems reasonable.  I guess.  Why is this needed?

I don't think it is other than for PPC.  If you're not variable endian
(which is only PPC to date), then you should know a priori what endian
you are from the #defines in userspace.

James

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-01 23:12   ` James Bottomley
@ 2017-02-02  5:08     ` Andy Lutomirski
  2017-02-05 11:48     ` Matt Turner
  1 sibling, 0 replies; 9+ messages in thread
From: Andy Lutomirski @ 2017-02-02  5:08 UTC (permalink / raw)
  To: James Bottomley
  Cc: Andrew Morton, Helge Deller, linux-kernel, linux-parisc,
	Michael Kerrisk, Linux API

On Wed, Feb 1, 2017 at 3:12 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de>
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

I find it vaguely odd even on PPC.  Surely you can tell what your
endianness is directly.  (An API to query the endianness of another
task would be useful, though.)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-01 23:12   ` James Bottomley
  2017-02-02  5:08     ` Andy Lutomirski
@ 2017-02-05 11:48     ` Matt Turner
  2017-02-05 13:15       ` Maciej W. Rozycki
  1 sibling, 1 reply; 9+ messages in thread
From: Matt Turner @ 2017-02-05 11:48 UTC (permalink / raw)
  To: James Bottomley
  Cc: Andrew Morton, Helge Deller, LKML, linux-parisc, Michael Kerrisk,
	linux-api

On Thu, Feb 2, 2017 at 12:12 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller <deller@gmx.de>
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

MIPS as well, but it seems strange to require the kernel to tell you
your endianness, when you can easily determine it yourself. Unless
there's something about this I don't understand.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-05 11:48     ` Matt Turner
@ 2017-02-05 13:15       ` Maciej W. Rozycki
  2017-02-15  5:20         ` Michael Ellerman
  0 siblings, 1 reply; 9+ messages in thread
From: Maciej W. Rozycki @ 2017-02-05 13:15 UTC (permalink / raw)
  To: Matt Turner
  Cc: James Bottomley, Andrew Morton, Helge Deller, LKML, linux-parisc,
	Michael Kerrisk, linux-api

On Sun, 5 Feb 2017, Matt Turner wrote:

> > I don't think it is other than for PPC.  If you're not variable endian
> > (which is only PPC to date), then you should know a priori what endian
> > you are from the #defines in userspace.
> 
> MIPS as well, but it seems strange to require the kernel to tell you
> your endianness, when you can easily determine it yourself. Unless
> there's something about this I don't understand.

 Many MIPS processors do have a reverse-endian control bit, which allows a 
user process to execute in the endianness opposite to the endianness the 
kernel runs in.  The feature has been around since 1991 and the R4000 CPU, 
however support is unlikely to be ever added to the MIPS/Linux port, due 
to the complexity required for byte-swapping all the data structures 
passed in memory between the kernel and the userland.  Does the PPC/Linux 
port actually implement this swapping?

  Maciej

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
  2017-02-05 13:15       ` Maciej W. Rozycki
@ 2017-02-15  5:20         ` Michael Ellerman
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Ellerman @ 2017-02-15  5:20 UTC (permalink / raw)
  To: Maciej W. Rozycki, Matt Turner
  Cc: James Bottomley, Andrew Morton, Helge Deller, LKML, linux-parisc,
	Michael Kerrisk, linux-api

"Maciej W. Rozycki" <macro@linux-mips.org> writes:

> On Sun, 5 Feb 2017, Matt Turner wrote:
>
>> > I don't think it is other than for PPC.  If you're not variable endian
>> > (which is only PPC to date), then you should know a priori what endian
>> > you are from the #defines in userspace.
>> 
>> MIPS as well, but it seems strange to require the kernel to tell you
>> your endianness, when you can easily determine it yourself. Unless
>> there's something about this I don't understand.
>
>  Many MIPS processors do have a reverse-endian control bit, which allows a 
> user process to execute in the endianness opposite to the endianness the 
> kernel runs in.  The feature has been around since 1991 and the R4000 CPU, 
> however support is unlikely to be ever added to the MIPS/Linux port, due 
> to the complexity required for byte-swapping all the data structures 
> passed in memory between the kernel and the userland.  Does the PPC/Linux 
> port actually implement this swapping?

No. Userspace can change endian, but it has to cope with the kernel
being in the original endian.

cheers

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-02-15  5:20 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-28 11:13 [PATCH] prctl: implement PR_GET_ENDIAN for all architectures Helge Deller
2017-02-01  0:26 ` Andrew Morton
2017-02-01 19:47   ` Helge Deller
2017-02-01 22:03     ` Andrew Morton
2017-02-01 23:12   ` James Bottomley
2017-02-02  5:08     ` Andy Lutomirski
2017-02-05 11:48     ` Matt Turner
2017-02-05 13:15       ` Maciej W. Rozycki
2017-02-15  5:20         ` Michael Ellerman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).