[PATCH 2/3] ARM: convert to generated system call tables

[Russell King - ARM Linux]

On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> 
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> > 
> > I'd still like to retain the ability to only add to EABI in the future.
> 
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?

To stop adding OABI syscalls altogether.  I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.

> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> > 
> > OABI-compat != ARM64-EABI-compat though.  They're two completely
> > different things.
> 
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.

The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.

I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me.  Even
for x86, all I care there is that it works, I've no knowledge of how
it works.

> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.

What's the point of the x32 mode?

> ARM64 has a separate list of syscalls for compat mode in 
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.

Looking through it, sort-of.  It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)

So... if you don't mind, this isn't an issue I care one iota about.

In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all.  I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.