[PATCH v4 00/24] ILP32 for ARM64

[arnd@arndb.de (Arnd Bergmann)]

On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
> > On Apr 14, 2015, at 3:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 
> >> On Tuesday 14 April 2015 11:33:13 Dr.  Philipp Tomsich wrote:
> >> Arnd,
> >> 
> >> After getting a good night?s sleep, the ?reuse the existing system call table? comment
> >> makes a little more sense as I construe it as having just one merged system call table
> >> for both LP64 and ILP32 and handling the differences through a different system call
> >> numbering in unistd.h towards LP64 and ILP32 processes.
> >> 
> >> If this is the intended implementation, I am not fully sold on the benefit: having a private
> >> copy of unistd.h for ARM64 seems to be a less readable and less maintenance-friendly
> >> solution to having separate tables.
> >> 
> >> We?re open to input on this and?if merging the system call tables is the consensus?
> >> would like to get the change underway as soon as possible.
> > 
> > There are multiple ways of doing this:
> > 
> > a) separate syscall table for arm64: as you say, this is the current approach,
> >   and I'd like to avoid that too
> > b) add syscalls for ilp32 as additional numbers in the normal lp64 version of
> >   asm-generic/unistd.h, and share the binary tables between ilp32 and lp64
> >   on aarch64
> > c) change asm-generic/unistd.h to generate three possible tables: instead of
> >   just native (lp64 or ilp32 depending on the arch), compat (support for
> >   existing ilp32 binaries on some architectures, there would also be a
> >   "modern" ilp32 variant that is a mix of the two, as your table today
> > d) don't use the asm-generic/unistd.h table for aarch64-ilp32 at all, but instead
> >   reuse the table from arch/arm64/include/asm/unistd32.h
> > 
> > I think you are referring to approach b) or c) above, but my preferred one
> > would actually be d).
> 
> D is the worst of all 4 options in my mind. The reason is when a new syscall is
> added, then you have to update that file too.

I don't know what the miscommunication is here, but the advantage of d is
specifically that it is /less/ work to maintain: With the current approach,
each new syscall that gets added needs to be checked to see if the normal
aarch64 version works or if it needs another wrapper, while with d) we
get the update for free, because we follow exactly what aarch32 is doing.

> Also d is worse than the rest as
> you no longer default to 64bit off_t which is not a good thing. 

That decision is up to the libc implementation, just as it is for the existing
aarch32 libc. The kernel just offers both versions and the libc can pick
one, or use the _LARGEFILE64_SOURCE hack that glibc has to also implement
both. It would probably be reasonable to use 64-bit off_t only for a libc
and ignore the old calls.

> B is just as bad and goes against using the generic syscall numbers. 

How so? The newly introduce syscalls then would be the generic ones.
 
> I was trying to model ilp32 so there was less maintain hassle if a new syscall was added. 
> 
> Also about time_t, my original patch had used 32bit but was asked to change
> it to the 64bit one. So now I am upset this being asked again to change it back.
> The review process for the linux kernel is much harder than the review process
> of gcc or even glibc now. 

For now, I'm just opening that discussion again, but the reason this
comes up again now is that a lot has happened in the meantime on this
front, and we have already decided to merge new architecture ports with
32-bit time_t since.

	Arnd