From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
Cc: Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Tycho Andersen <tycho@tycho.ws>,
Daniel Colascione <dancol@google.com>,
Florian Weimer <fweimer@redhat.com>,
Carlos O'Donell <carlos@redhat.com>,
Rich Felker <dalias@libc.org>
Subject: Re: Cleaning up numbering for new x86 syscalls?
Date: Fri, 30 Nov 2018 23:25:09 +0000 (GMT) [thread overview]
Message-ID: <alpine.LFD.2.21.1811302309530.25979@eddie.linux-mips.org> (raw)
In-Reply-To: <87cbf7b4-9e77-adc1-8e18-14dd206f0b79@petrovitsch.priv.at>
On Wed, 21 Nov 2018, Bernd Petrovitsch wrote:
> And yes, lots of stuff will not compile out of the box (especially if
> one uses a somewhat sane set of gcc options - not only -Wall -Wextra
> -Werror) but if one gets software to compile for i386 and x86_64,
> getting it to compile for x32 is a Friday afternoon job (more or less).
> And yes, there is enough hardware/systems out there that uses 64bit CPUs
> (for whatever reason - if only that one can't get a 32bit CPU for that
> board) but will never ever need more than 2-3 GB RAM .....
The functionally equivalent 64-bit ILP32 MIPS n32 ABI has been around
supported by Linux and the GNU toolchain for some 17 years now and people
have been using it, so by now any sane piece of software that does not use
handcoded assembly should work out of the box for the x86-64 x32 ABI as
well.
NB the important advantage of an LP64 ABI over an ILP32 ABI is the
ability to mmap(2) files that exceed 4GiB in size (and in reality even
smaller ones, as some user VM space is surely needed for other stuff),
regardless of how much physical RAM is actually supported or has been
installed.
And these days even a web browser can easily overrun a 4GiB VM space. :(
FWIW,
Maciej
next prev parent reply other threads:[~2018-11-30 23:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 0:22 Andy Lutomirski
2018-11-20 7:33 ` Ingo Molnar
2018-11-20 23:04 ` Bernd Petrovitsch
2018-11-30 23:25 ` Maciej W. Rozycki [this message]
2018-11-20 9:03 ` Florian Weimer
2018-11-20 15:23 ` Andy Lutomirski
2018-11-20 18:07 ` Josh Poimboeuf
2018-11-21 17:23 ` Arnd Bergmann
2018-11-20 16:48 ` Tycho Andersen
2018-11-21 17:14 ` Arnd Bergmann
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=alpine.LFD.2.21.1811302309530.25979@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=bernd@petrovitsch.priv.at \
--cc=bp@alien8.de \
--cc=carlos@redhat.com \
--cc=dalias@libc.org \
--cc=dancol@google.com \
--cc=fweimer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tycho@tycho.ws \
--cc=x86@kernel.org \
/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
Powered by JetHome