public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
Date: Tue, 29 Mar 2016 23:39:48 +0200	[thread overview]
Message-ID: <5332965.FKfI1zIepV@wuerfel> (raw)
In-Reply-To: <alpine.DEB.2.10.1603292051150.15654@digraph.polyomino.org.uk>

On Tuesday 29 March 2016 21:00:56 Joseph Myers wrote:
> On Tue, 29 Mar 2016, Arnd Bergmann wrote:
> 
> > > I think so (along with using wordsize-64 sysdeps directories as far as 
> > > possible, like x32 does).  But design questions for a glibc port really 
> > > belong on libc-alpha to get any sort of community consensus.
> > 
> > I thought the wordsize-64 stuff was for the x86 mode where they
> > define __kernel_long_t as 64-bit. We don't really want to do that in
> > the kernel for new 32-bit architectures, that would make the kernel
> > ABI different from all the existing architectures.
> 
> In general the wordsize-64 directories cover various relations of the form 
> "function X is an alias for function Y", which derive from "type X is 
> ABI-compatible with type Y".  (Unfortunately, the precise set isn't 
> well-defined, resulting in problems for cases that want a subset of those 
> relations - e.g. MIPS n64 where struct stat and struct stat64 are 
> different, and so sysdeps/unix/sysv/linux/wordsize-64 isn't used.)

For all new 32-bit architectures like this, the kernel should at least
behave in a consistent way, but it's somewhere inbetween wordsize-32 and
wordsize-64 for 32-bit architectures, because off_t and ino_t are mapped
to the 64-bit __kernel_loff_t and __kernel_ino_t, while time_t, clock_t
and size_t are mapped to 32 bit types.

> The person doing the port will need to do a detailed review of the exact 
> effects of the wordsize-64 directories in current glibc, and which of 
> those effects are appropriate for this port, to determine what is 
> appropriate, and to include that analysis with the port submission.

I think the analysis will have to be about two separate things:

* Whether new 32-bit architectures in general should use wordsize-32
  or wordsize-64 or something else, based on what you write above.
  I would still guess that we are better off adapting wordsize-32
  to the current kernel ABI for 32-bit architectures while leaving
  wordsize-64 to real 64-bit architectures and x86/x32.

* How we deal with the special case of this architecture having
  nonstandard calling conventions for a couple of syscalls that
  take 64-bit arguments in a single register rather than two registers
  as every other 32-bit architecture does.

	Arnd

  reply	other threads:[~2016-03-29 21:39 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 17:22 [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov
2016-01-14 17:22 ` [PATCH v6 01/21] arm64: ilp32: add documentation on the ILP32 ABI " Yury Norov
2016-01-14 17:22 ` [PATCH v6 02/21] arm64: ensure the kernel is compiled for LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 03/21] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 04/21] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2016-01-14 17:23 ` [PATCH v6 05/21] arm64: compat: change config dependences to aarch32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 06/21] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 07/21] thread: move thread bits accessors to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 08/21] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2016-01-14 17:23 ` [PATCH v6 09/21] arm64: ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 10/21] arm64: introduce binfmt_elf32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 11/21] arm64: ilp32: introduce binfmt_ilp32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 12/21] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 13/21] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2016-01-14 17:23 ` [PATCH v6 14/21] arm64: signal: wrap struct ucontext, fp and lr with struct sigframe Yury Norov
2016-01-14 17:23 ` [PATCH v6 15/21] arm64: signal: share lp64 signal routines to ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 16/21] arm64: signal32: move ilp32 and aarch32 common code to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 17/21] arm64: ilp32: introduce ilp32-specific handlers for sigframe Yury Norov
2016-02-29  8:27   ` Andreas Schwab
2016-01-14 17:23 ` [PATCH v6 18/21] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2016-01-14 17:23 ` [PATCH v6 19/21] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 20/21] all: s390: make compat wrappers the generic solution Yury Norov
2016-01-14 18:11   ` Yury Norov
2016-01-15 12:46   ` Heiko Carstens
     [not found]     ` <20160119175223.GA6603@yury-N73SV>
2016-01-20  8:16       ` Heiko Carstens
2016-01-20 12:17         ` Yury Norov
2016-01-14 17:23 ` [PATCH v6 21/21] arm64: ilp32: wrap syscalls to remove top 32-bit vulnerability Yury Norov
2016-01-18 13:18 ` [RFC5 PATCH v6 00/21] ILP32 for ARM64 Zhangjian (Bamvor)
2016-01-18 13:26   ` Andreas Schwab
2016-01-18 13:41     ` Bamvor Zhang Jian
2016-01-29  9:59 ` Zhangjian (Bamvor)
2016-01-29 17:09   ` Yury Norov
2016-01-30  4:15     ` Zhangjian (Bamvor)
2016-02-18 22:35       ` Yury Norov
2016-02-19  8:23         ` Arnd Bergmann
2016-02-19 12:59           ` Yury Norov
2016-02-19 14:06             ` Arnd Bergmann
2016-02-29 15:39           ` Yury Norov
2016-02-29 16:00           ` Andreas Schwab
2016-02-29 16:30             ` Arnd Bergmann
2016-02-25 10:50         ` Andreas Schwab
2016-02-25 20:28           ` Yury Norov
2016-03-18 10:28             ` Zhangjian (Bamvor)
2016-03-18 15:49               ` Yury Norov
2016-03-18 15:55                 ` Alexander Graf
2016-03-18 16:46                   ` Yury Norov
2016-03-20  8:12                     ` Zhangjian (Bamvor)
2016-03-21 11:23                       ` Zhangjian (Bamvor)
2016-03-21 18:43                         ` Yury Norov
2016-03-22  1:49                           ` Yury Norov
2016-03-21  9:07                 ` Andreas Schwab
2016-03-21  9:43                   ` Arnd Bergmann
2016-03-21 10:52                     ` Andreas Schwab
2016-03-21 17:02                       ` Arnd Bergmann
2016-03-26 12:36                     ` Zhangjian (Bamvor)
2016-03-29 10:58                       ` Arnd Bergmann
2016-03-29 12:01                         ` Yury Norov
2016-03-29 12:42                           ` Arnd Bergmann
2016-03-29 13:21                           ` Zhangjian (Bamvor)
2016-03-29 13:27                             ` Arnd Bergmann
2016-03-29 15:54                               ` Joseph Myers
2016-03-29 19:30                                 ` Arnd Bergmann
2016-03-29 20:15                                   ` Joseph Myers
2016-03-29 20:24                                     ` Arnd Bergmann
2016-03-29 21:00                                       ` Joseph Myers
2016-03-29 21:39                                         ` Arnd Bergmann [this message]
2016-03-31  7:35                               ` Zhangjian (Bamvor)
2016-03-21 18:40                   ` Yury Norov
2016-03-26 13:08                     ` Zhangjian (Bamvor)
2016-03-26 13:45                     ` Zhangjian (Bamvor)
2016-03-26 22:46                       ` Yury Norov

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=5332965.FKfI1zIepV@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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