From: Michael Ellerman <mpe@ellerman.id.au>
To: "Maciej W. Rozycki" <macro@linux-mips.org>,
Matt Turner <mattst88@gmail.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Andrew Morton <akpm@linux-foundation.org>,
Helge Deller <deller@gmx.de>, LKML <linux-kernel@vger.kernel.org>,
"linux-parisc\@vger.kernel.org" <linux-parisc@vger.kernel.org>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
linux-api@vger.kernel.org
Subject: Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures
Date: Wed, 15 Feb 2017 16:20:23 +1100 [thread overview]
Message-ID: <87bmu4kp2g.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <alpine.LFD.2.20.1702051300010.27997@eddie.linux-mips.org>
"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
prev parent reply other threads:[~2017-02-15 5:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-28 11:13 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmu4kp2g.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=deller@gmx.de \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mattst88@gmail.com \
--cc=mtk.manpages@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®