Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 04 May 2015 12:29:52 Arnd Bergmann wrote:
>
> For 'struct stat', I ended up introducing a new structure on arm32 that
> matches the layout of arm64 (and I did the same for all other 32-bit
> architectures that have a 64-bit counterpart). This means we can share
> the same system calls between arm64-lp64, arm64-ilp32 and arm32 with
> 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while
> using the existing compat handling for the original 'struct stat'
> emulation in both arm32 and arm64-aarch32.
>
> However, for ipc, the situation is different: I found a way to use
> extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the
> ipc system calls will still use normal 32-bit data structures
> on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32,
> and will have to #ifdef the three header files there to choose between
> the two implementations.
I realized that this may need some more clarification. What I meant is
that we can extend the current 32-bit version of struct semid64_ds
and the others on arm32, and in the same way extend compat_semid64_ds
on arm64, but you cannot use that on arm64-ilp32 for other reasons.
The solution here is to redefine the normal arm64 semid64_ds so ilp32
see a structure with the same layout as lp64, and then use sys_semctl()
for arm64-ilp32 but use compat_sys_semctl() for aarch32-compat.
The definition would be something like
#ifdef __LP64__
#include
#else
struct semid64_ds {
struct ipc64_perm sem_perm; /* permissions .. see ipc.h */
__kernel_time_t sem_otime; /* last semop time */
__kernel_time_t sem_ctime; /* last change time */
__u64 sem_nsems; /* no. of semaphores in array */
__u64 __unused3;
__u64 __unused4;
};
#endif
Alternatively, we could use the same definition for both lp64 and ilp32,
which would change the type mangling but not the binary structure.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 04 May 2015 12:29:52 Arnd Bergmann wrote:
For 'struct stat', I ended up introducing a new structure on arm32 that
matches the layout of arm64 (and I did the same for all other 32-bit
architectures that have a 64-bit counterpart). This means we can share
the same system calls between arm64-lp64, arm64-ilp32 and arm32 with
64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while
using the existing compat handling for the original 'struct stat'
emulation in both arm32 and arm64-aarch32.
However, for ipc, the situation is different: I found a way to use
extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the
ipc system calls will still use normal 32-bit data structures
on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32,
and will have to #ifdef the three header files there to choose between
the two implementations.
I realized that this may need some more clarification. What I meant is
that we can extend the current 32-bit version of struct semid64_ds
and the others on arm32, and in the same way extend compat_semid64_ds
on arm64, but you cannot use that on arm64-ilp32 for other reasons.
The solution here is to redefine the normal arm64 semid64_ds so ilp32
see a structure with the same layout as lp64, and then use sys_semctl()
for arm64-ilp32 but use compat_sys_semctl() for aarch32-compat.
The definition would be something like
#ifdef __LP64__
#include asm-generic/sembuf.h
#else
struct semid64_ds {
struct ipc64_perm sem_perm; /* permissions .. see ipc.h */
__kernel_time_t sem_otime; /* last semop time */
__kernel_time_t sem_ctime; /* last change time */
__u64 sem_nsems; /* no. of semaphores in array */
__u64 __unused3;
__u64 __unused4;
};
#endif
Alternatively, we could use the same definition for both lp64 and ilp32,
which would change the type mangling but not the binary structure.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 04 May 2015 12:32:30 Dr. Philipp Tomsich wrote: > Arnd, > > Where can I pull this prototype implementation from? > As we are working on getting a final ILP32 change-set ready, I’d like to make > sure that we base this on the latest consensus for new ILP32 ABIs on 64bit > machines. > I currently have an early prototype that I have done on top of another working branch. You can find it at git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-syscalls to see the current state, but as this has so far not been posted for review to a wider group of people, I expect that a lot of details will change, possibly even the overall approach I've taken. See also my introduction at https://lists.linaro.org/pipermail/y2038/2015-May/000178.html Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Arnd, Where can I pull this prototype implementation from? As we are working on getting a final ILP32 change-set ready, I’d like to make sure that we base this on the latest consensus for new ILP32 ABIs on 64bit machines. Thanks, Philipp. > On 04 May 2015, at 12:29, Arnd Bergmann wrote: > > On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote: >> Given Catalin's comments from yesterday, I think we can just fix the >> definitions of 'struct stat64' for asm-generic to make it have the same >> layout as the 64-bit version of 'struct stat', and use that for >> aarch64-ilp32. >> >> Similarly for the four sysvipc headers, we can have a modified version of >> the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout >> for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. > > To pick up that earlier thread, I now have a prototype implementation for > converting all 32-bit architectures to use 64-bit time_t. > > For 'struct stat', I ended up introducing a new structure on arm32 that > matches the layout of arm64 (and I did the same for all other 32-bit > architectures that have a 64-bit counterpart). This means we can share > the same system calls between arm64-lp64, arm64-ilp32 and arm32 with > 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while > using the existing compat handling for the original 'struct stat' > emulation in both arm32 and arm64-aarch32. > > However, for ipc, the situation is different: I found a way to use > extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the > ipc system calls will still use normal 32-bit data structures > on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32, > and will have to #ifdef the three header files there to choose between > the two implementations. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote: > Given Catalin's comments from yesterday, I think we can just fix the > definitions of 'struct stat64' for asm-generic to make it have the same > layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32. > > Similarly for the four sysvipc headers, we can have a modified version of > the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout > for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. To pick up that earlier thread, I now have a prototype implementation for converting all 32-bit architectures to use 64-bit time_t. For 'struct stat', I ended up introducing a new structure on arm32 that matches the layout of arm64 (and I did the same for all other 32-bit architectures that have a 64-bit counterpart). This means we can share the same system calls between arm64-lp64, arm64-ilp32 and arm32 with 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while using the existing compat handling for the original 'struct stat' emulation in both arm32 and arm64-aarch32. However, for ipc, the situation is different: I found a way to use extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the ipc system calls will still use normal 32-bit data structures on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32, and will have to #ifdef the three header files there to choose between the two implementations. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote: Given Catalin's comments from yesterday, I think we can just fix the definitions of 'struct stat64' for asm-generic to make it have the same layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32. Similarly for the four sysvipc headers, we can have a modified version of the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. To pick up that earlier thread, I now have a prototype implementation for converting all 32-bit architectures to use 64-bit time_t. For 'struct stat', I ended up introducing a new structure on arm32 that matches the layout of arm64 (and I did the same for all other 32-bit architectures that have a 64-bit counterpart). This means we can share the same system calls between arm64-lp64, arm64-ilp32 and arm32 with 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while using the existing compat handling for the original 'struct stat' emulation in both arm32 and arm64-aarch32. However, for ipc, the situation is different: I found a way to use extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the ipc system calls will still use normal 32-bit data structures on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32, and will have to #ifdef the three header files there to choose between the two implementations. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Arnd, Where can I pull this prototype implementation from? As we are working on getting a final ILP32 change-set ready, I’d like to make sure that we base this on the latest consensus for new ILP32 ABIs on 64bit machines. Thanks, Philipp. On 04 May 2015, at 12:29, Arnd Bergmann a...@arndb.de wrote: On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote: Given Catalin's comments from yesterday, I think we can just fix the definitions of 'struct stat64' for asm-generic to make it have the same layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32. Similarly for the four sysvipc headers, we can have a modified version of the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. To pick up that earlier thread, I now have a prototype implementation for converting all 32-bit architectures to use 64-bit time_t. For 'struct stat', I ended up introducing a new structure on arm32 that matches the layout of arm64 (and I did the same for all other 32-bit architectures that have a 64-bit counterpart). This means we can share the same system calls between arm64-lp64, arm64-ilp32 and arm32 with 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while using the existing compat handling for the original 'struct stat' emulation in both arm32 and arm64-aarch32. However, for ipc, the situation is different: I found a way to use extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the ipc system calls will still use normal 32-bit data structures on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32, and will have to #ifdef the three header files there to choose between the two implementations. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 04 May 2015 12:32:30 Dr. Philipp Tomsich wrote: Arnd, Where can I pull this prototype implementation from? As we are working on getting a final ILP32 change-set ready, I’d like to make sure that we base this on the latest consensus for new ILP32 ABIs on 64bit machines. I currently have an early prototype that I have done on top of another working branch. You can find it at git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-syscalls to see the current state, but as this has so far not been posted for review to a wider group of people, I expect that a lot of details will change, possibly even the overall approach I've taken. See also my introduction at https://lists.linaro.org/pipermail/y2038/2015-May/000178.html Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 20 April 2015 16:56:00 Catalin Marinas wrote:
> On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> > On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > | typedef unsigned short __kernel_mode_t;
> > | typedef unsigned short __kernel_ipc_pid_t;
> >
> > Both of these affect all sysvipc, but very little else
> >
> > | typedef unsigned short __kernel_uid_t;
> > | typedef unsigned short __kernel_gid_t;
> >
> > sysvipc, ncpfs, and core dumps (probably fine since they are separate
> > anyway),
>
> Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
> to me like we can just use the compat variants with the generic
> definitions for the types above (unless I missed something). Similarly
> for shmat, compat_sys_shmat just does some compat_ptr casting.
Right.
> > | typedef unsigned short __kernel_old_dev_t; /* compat gets this
> > wrong */
> >
> > old-style loopdev ioctl
> >
> > | struct stat { ... } /* possibly not needed */
> >
> > - lustre ioctls (needs to be fixed anyway)
> > - old stat syscalls (won't be used with asm-generic/unistd.h)
> >
> > | struct stat64 { ... }
> >
> > - lustre ioctls
> > - new style stat syscalls
>
> For stat64 the wrappers don't look complicated, so we could add arm64
> ILP32-specific ones.
stat is never easy ;-)
Note that for new architectures, we use 'struct stat64' on 32-bit systems
but 'struct stat' on 64-bit systems. Old architectures like arch/arm has
both, and neither of them matches the on from arch/arm64.
Also, the asm-generic definition of 'struct stat64' is wrong and really
needs to be fixed to have the same layout that 'struct stat' has on
a 64-bit architecture. The only difference between the two is the size
of the time related 'st_atime' etc members, and having them defined
this way was my biggest mistake when I created the uapi/asm-generic
headers.
> > So, in essence the difference comes down to the syscalls for stat
> > and ipc. If we use the aarch32 data types, we can share the
> > fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
> > and shmctl compat system calls between aarch32-compat and
> > aarch64-ilp32-compat. Otherwise we have to duplicate or extend
> > them to cover both cases at runtime. That would be rather ugly
> > but entirely doable. The ioctls are hardly affected, the few
> > ones that differ once __kernel_long_t matches could easily be
> > fixed up as you say.
>
> I'd prefer a cleaner ABI even if we are to write some specific wrappers.
Ok, makes sense. As I replied to Philipp later, even with the
cleaner definition of 'stat64' and the sysipc syscalls, we should
be able to trivially reuse the native 64-bit version in the way that
the current patch set does for a lot of other syscalls, but keep all
the other syscalls using the normal 32-bit __kernel_long_t variants
that we already have.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > > g) create a new ABI that does things in exactly the way that we
> > > would use as the native syscall interface if we had an ilp32
> > > kernel running on aarch64 with the asm-generic/unistd.h.
> > > This would mean a 32-bit __kernel_long_t and time_t, but extending
> > > time_t in the long run, together with aarch32 and i386.
> > > This one is particularly interesting for people that are interested
> > > in maximum posix compliance and in having a "nice" ABI, in particular
> > > if there is a slight chance that within the next decade we have
> > > reason to support building an arch/arm64 kernel itself in
> > > aarch64-ilp32 mode.
> >
> > I don't think there is a much difference between g) and e). The reason
> > we re-define many structures in asm/compat.h is because we don't have a
> > generic compat_* definition (e.g. compat_timespec, compat_timeval,
> > compat_flock, compat_flock64; anyway, I think some of these may not even
> > be needed with the canonical set of syscalls). The signal related
> > structures need to be handled differently for AArch32 and AArch64-ILP32
> > anyway because of the difference in the register set.
>
> Interesting observation, I had not guessed this.
>
> Let's list the differences, this is what I could find:
>
> | #define FIOQSIZE0x545E
>
> probably broken on arm64 already, should be investigated
Yes, it seems broken. arm64 uses the generic FIOQSIZE which doesn't
match the compat one.
> | typedef unsigned short __kernel_mode_t;
> | typedef unsigned short __kernel_ipc_pid_t;
>
> Both of these affect all sysvipc, but very little else
>
> | typedef unsigned short __kernel_uid_t;
> | typedef unsigned short __kernel_gid_t;
>
> sysvipc, ncpfs, and core dumps (probably fine since they are separate
> anyway),
Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
to me like we can just use the compat variants with the generic
definitions for the types above (unless I missed something). Similarly
for shmat, compat_sys_shmat just does some compat_ptr casting.
> | typedef unsigned short __kernel_old_dev_t; /* compat gets this
> wrong */
>
> old-style loopdev ioctl
>
> | struct stat { ... } /* possibly not needed */
>
> - lustre ioctls (needs to be fixed anyway)
> - old stat syscalls (won't be used with asm-generic/unistd.h)
>
> | struct stat64 { ... }
>
> - lustre ioctls
> - new style stat syscalls
For stat64 the wrappers don't look complicated, so we could add arm64
ILP32-specific ones.
I'm not sure about the ioctls affected, I haven't checked.
> So, in essence the difference comes down to the syscalls for stat
> and ipc. If we use the aarch32 data types, we can share the
> fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
> and shmctl compat system calls between aarch32-compat and
> aarch64-ilp32-compat. Otherwise we have to duplicate or extend
> them to cover both cases at runtime. That would be rather ugly
> but entirely doable. The ioctls are hardly affected, the few
> ones that differ once __kernel_long_t matches could easily be
> fixed up as you say.
I'd prefer a cleaner ABI even if we are to write some specific wrappers.
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On 2015/4/17 21:17, Arnd Bergmann wrote: On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new "compat" layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be From my point of view, Aarch32 and Aarch64 ILP32 should be not exclusive, otherwise, it would be a little bit hard to maintenance. IIUC, ILP32 address an optional road for the application migrating from arm 32bit SOC to arm64 SOC. There are lots of application in huawei we need to support in the same product. And different subsystem of the product may choose the different road to migrate. E.g. Aarch32 -> Aarch64 LP64, arm 32bit -> Aarch64 ILP32, arm 32bit -> Aarch64, ... (Those application running on one kernel of course). regards bamvor f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a "nice" ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user
Re: [PATCH v4 00/24] ILP32 for ARM64
On 2015/4/17 21:17, Arnd Bergmann wrote: On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be From my point of view, Aarch32 and Aarch64 ILP32 should be not exclusive, otherwise, it would be a little bit hard to maintenance. IIUC, ILP32 address an optional road for the application migrating from arm 32bit SOC to arm64 SOC. There are lots of application in huawei we need to support in the same product. And different subsystem of the product may choose the different road to migrate. E.g. Aarch32 - Aarch64 LP64, arm 32bit - Aarch64 ILP32, arm 32bit - Aarch64, ... (Those application running on one kernel of course). regards bamvor f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 20 April 2015 16:56:00 Catalin Marinas wrote:
On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
| typedef unsigned short __kernel_mode_t;
| typedef unsigned short __kernel_ipc_pid_t;
Both of these affect all sysvipc, but very little else
| typedef unsigned short __kernel_uid_t;
| typedef unsigned short __kernel_gid_t;
sysvipc, ncpfs, and core dumps (probably fine since they are separate
anyway),
Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
to me like we can just use the compat variants with the generic
definitions for the types above (unless I missed something). Similarly
for shmat, compat_sys_shmat just does some compat_ptr casting.
Right.
| typedef unsigned short __kernel_old_dev_t; /* compat gets this
wrong */
old-style loopdev ioctl
| struct stat { ... } /* possibly not needed */
- lustre ioctls (needs to be fixed anyway)
- old stat syscalls (won't be used with asm-generic/unistd.h)
| struct stat64 { ... }
- lustre ioctls
- new style stat syscalls
For stat64 the wrappers don't look complicated, so we could add arm64
ILP32-specific ones.
stat is never easy ;-)
Note that for new architectures, we use 'struct stat64' on 32-bit systems
but 'struct stat' on 64-bit systems. Old architectures like arch/arm has
both, and neither of them matches the on from arch/arm64.
Also, the asm-generic definition of 'struct stat64' is wrong and really
needs to be fixed to have the same layout that 'struct stat' has on
a 64-bit architecture. The only difference between the two is the size
of the time related 'st_atime' etc members, and having them defined
this way was my biggest mistake when I created the uapi/asm-generic
headers.
So, in essence the difference comes down to the syscalls for stat
and ipc. If we use the aarch32 data types, we can share the
fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
and shmctl compat system calls between aarch32-compat and
aarch64-ilp32-compat. Otherwise we have to duplicate or extend
them to cover both cases at runtime. That would be rather ugly
but entirely doable. The ioctls are hardly affected, the few
ones that differ once __kernel_long_t matches could easily be
fixed up as you say.
I'd prefer a cleaner ABI even if we are to write some specific wrappers.
Ok, makes sense. As I replied to Philipp later, even with the
cleaner definition of 'stat64' and the sysipc syscalls, we should
be able to trivially reuse the native 64-bit version in the way that
the current patch set does for a lot of other syscalls, but keep all
the other syscalls using the normal 32-bit __kernel_long_t variants
that we already have.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
g) create a new ABI that does things in exactly the way that we
would use as the native syscall interface if we had an ilp32
kernel running on aarch64 with the asm-generic/unistd.h.
This would mean a 32-bit __kernel_long_t and time_t, but extending
time_t in the long run, together with aarch32 and i386.
This one is particularly interesting for people that are interested
in maximum posix compliance and in having a nice ABI, in particular
if there is a slight chance that within the next decade we have
reason to support building an arch/arm64 kernel itself in
aarch64-ilp32 mode.
I don't think there is a much difference between g) and e). The reason
we re-define many structures in asm/compat.h is because we don't have a
generic compat_* definition (e.g. compat_timespec, compat_timeval,
compat_flock, compat_flock64; anyway, I think some of these may not even
be needed with the canonical set of syscalls). The signal related
structures need to be handled differently for AArch32 and AArch64-ILP32
anyway because of the difference in the register set.
Interesting observation, I had not guessed this.
Let's list the differences, this is what I could find:
| #define FIOQSIZE0x545E
probably broken on arm64 already, should be investigated
Yes, it seems broken. arm64 uses the generic FIOQSIZE which doesn't
match the compat one.
| typedef unsigned short __kernel_mode_t;
| typedef unsigned short __kernel_ipc_pid_t;
Both of these affect all sysvipc, but very little else
| typedef unsigned short __kernel_uid_t;
| typedef unsigned short __kernel_gid_t;
sysvipc, ncpfs, and core dumps (probably fine since they are separate
anyway),
Not all ipc functions are affected AFAICT. msgsnd, msgrcv, msgctl look
to me like we can just use the compat variants with the generic
definitions for the types above (unless I missed something). Similarly
for shmat, compat_sys_shmat just does some compat_ptr casting.
| typedef unsigned short __kernel_old_dev_t; /* compat gets this
wrong */
old-style loopdev ioctl
| struct stat { ... } /* possibly not needed */
- lustre ioctls (needs to be fixed anyway)
- old stat syscalls (won't be used with asm-generic/unistd.h)
| struct stat64 { ... }
- lustre ioctls
- new style stat syscalls
For stat64 the wrappers don't look complicated, so we could add arm64
ILP32-specific ones.
I'm not sure about the ioctls affected, I haven't checked.
So, in essence the difference comes down to the syscalls for stat
and ipc. If we use the aarch32 data types, we can share the
fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
and shmctl compat system calls between aarch32-compat and
aarch64-ilp32-compat. Otherwise we have to duplicate or extend
them to cover both cases at runtime. That would be rather ugly
but entirely doable. The ioctls are hardly affected, the few
ones that differ once __kernel_long_t matches could easily be
fixed up as you say.
I'd prefer a cleaner ABI even if we are to write some specific wrappers.
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote: > More comments below. > > > On 17 Apr 2015, at 16:46, Catalin Marinas wrote: > > > > Even in this case, we could enable AArch32 compat knowing that ioctls > > wouldn't work. If this is important, we can add an option to enable > > ioctl support for ILP32 and re-target the asm/compat.h definitions. > > > >> g) create a new ABI that does things in exactly the way that we > >> would use as the native syscall interface if we had an ilp32 > >> kernel running on aarch64 with the asm-generic/unistd.h. > >> This would mean a 32-bit __kernel_long_t and time_t, but extending > >> time_t in the long run, together with aarch32 and i386. > >> This one is particularly interesting for people that are interested > >> in maximum posix compliance and in having a "nice" ABI, in particular > >> if there is a slight chance that within the next decade we have > >> reason to support building an arch/arm64 kernel itself in > >> aarch64-ilp32 mode. > > I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as > it > has full support for 64bit arithmetic anyway. I also believe that other > kernel > internals (e.g. filesystems and inode-numbering) would use native 64bit types. > > The differences on the kernel side would mainly rest in that only a 32bit > address > space could reasonably be managed. So a native ILP32 ABI would differ from > the LP64 ABI mainly in how sizeof(long) is represented in the user-space. > > In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit > time_t. We normally like to all newly architectures to have an identical ABI though, which I think would be more important here. 64-bit time_t of course is what we want all architectures to have in principle, but we didn't do it for nios2 because of the added complexity. I think it's more likely to have no __kernel_time_t to defined at some point and only provide __kernel_time64_t in the future for new architectures, but we have not even introduced that. > However, it would be nice to get agreement on the normal 32-bit ABI > for time_t and timespec first, and then use the same thing everywhere. > >>> > >>> Do you mean for native 32-bit architectures? I think OpenBSD uses a > >>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well. > >> > >> Yes, and I'm working on that for Linux. The first step involves fixing > >> the kernel, one file at a time, changing all users of time_t to use > >> some other type (ktime_t or time64_t in most cases) instead, and > >> introducing > >> additional system calls to handle the boundary to user space without > >> breaking stuff. See my presentation at > >> http://elinux.org/ELC_2015_Presentations > >> for more detail. > > > > The approach here is primarily to fix the problem for existing 32-bit > > architectures by adding a new syscall and that's fine. But what if we > > enforce 64-bit time_t for all _new_ architectures? > > This boils down to whether we can define all the new syscalls _right now_ and > get the new (extended) compat-layer set up. In this case we could have a > userspace > implementation that already conforms to this for ILP32. > > Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate > with everyone else. > > Although it feels wrong to add another ABI that has a known limitation, this > may > in fact be the easiest way, as any fix to ILP32 would be done together with > the > fixes to all other 32bit ABIs. > > So, while I would like to have a 64bit time_t for ILP32 based on principle, I > do see > the 32bit time_t path as the most pragmatic way forward… especially, as this > unlinks > getting “some form of” ILP32 merged from resolving the 64bit time_t issue > across > all architectures. Given Catalin's comments from yesterday, I think we can just fix the definitions of 'struct stat64' for asm-generic to make it have the same layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32. Similarly for the four sysvipc headers, we can have a modified version of the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote: More comments below. On 17 Apr 2015, at 16:46, Catalin Marinas catalin.mari...@arm.com wrote: Even in this case, we could enable AArch32 compat knowing that ioctls wouldn't work. If this is important, we can add an option to enable ioctl support for ILP32 and re-target the asm/compat.h definitions. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it has full support for 64bit arithmetic anyway. I also believe that other kernel internals (e.g. filesystems and inode-numbering) would use native 64bit types. The differences on the kernel side would mainly rest in that only a 32bit address space could reasonably be managed. So a native ILP32 ABI would differ from the LP64 ABI mainly in how sizeof(long) is represented in the user-space. In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t. We normally like to all newly architectures to have an identical ABI though, which I think would be more important here. 64-bit time_t of course is what we want all architectures to have in principle, but we didn't do it for nios2 because of the added complexity. I think it's more likely to have no __kernel_time_t to defined at some point and only provide __kernel_time64_t in the future for new architectures, but we have not even introduced that. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. The approach here is primarily to fix the problem for existing 32-bit architectures by adding a new syscall and that's fine. But what if we enforce 64-bit time_t for all _new_ architectures? This boils down to whether we can define all the new syscalls _right now_ and get the new (extended) compat-layer set up. In this case we could have a userspace implementation that already conforms to this for ILP32. Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate with everyone else. Although it feels wrong to add another ABI that has a known limitation, this may in fact be the easiest way, as any fix to ILP32 would be done together with the fixes to all other 32bit ABIs. So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks getting “some form of” ILP32 merged from resolving the 64bit time_t issue across all architectures. Given Catalin's comments from yesterday, I think we can just fix the definitions of 'struct stat64' for asm-generic to make it have the same layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32. Similarly for the four sysvipc headers, we can have a modified version of the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > - If we do not use the exact data structures that we have on aarch32,
> > then I think we should make aarch32 emulation and aarch64-ilp32
> > emulation mutually exclusive, and provide two separate asm/compat.h
> > header files that contain the differences. In this case, we should
> > try to come up with an ABI that makes the most sense for the majority
> > of the use cases that people are interested in. The two most likely
> > choices here would be
> >
> > f) create a new ABI that follows exactly what x32 did. This is a
> > variation of the earlier b), c), or d), but with the change of
> > fixing ioctl support by using a matching asm/compat.h. This
> > would not be entirely POSIX compliant, but it would be a nice
> > hack to get the highest performance in microbenchmarks, as it
> > avoids most of the compat layer. Over time, it can get extended
> > to coexist with aarch32 emulation, but that may take a few years.
>
> Even in this case, we could enable AArch32 compat knowing that ioctls
> wouldn't work. If this is important, we can add an option to enable
> ioctl support for ILP32 and re-target the asm/compat.h definitions.
We can allow them to coexist, but I'd only do that in mainline after
fixing all existing problems. Otherwise we can end up with user space
that tries to use the wrong ioctl API, and fixing the kernel breaks
the application, without a way for the kernel to detect which behavior
the user expects.
> > g) create a new ABI that does things in exactly the way that we
> > would use as the native syscall interface if we had an ilp32
> > kernel running on aarch64 with the asm-generic/unistd.h.
> > This would mean a 32-bit __kernel_long_t and time_t, but extending
> > time_t in the long run, together with aarch32 and i386.
> > This one is particularly interesting for people that are interested
> > in maximum posix compliance and in having a "nice" ABI, in particular
> > if there is a slight chance that within the next decade we have
> > reason to support building an arch/arm64 kernel itself in
> > aarch64-ilp32 mode.
>
> I don't think there is a much difference between g) and e). The reason
> we re-define many structures in asm/compat.h is because we don't have a
> generic compat_* definition (e.g. compat_timespec, compat_timeval,
> compat_flock, compat_flock64; anyway, I think some of these may not even
> be needed with the canonical set of syscalls). The signal related
> structures need to be handled differently for AArch32 and AArch64-ILP32
> anyway because of the difference in the register set.
Interesting observation, I had not guessed this.
Let's list the differences, this is what I could find:
| #define FIOQSIZE0x545E
probably broken on arm64 already, should be investigated
| typedef unsigned short __kernel_mode_t;
| typedef unsigned short __kernel_ipc_pid_t;
Both of these affect all sysvipc, but very little else
| typedef unsigned short __kernel_uid_t;
| typedef unsigned short __kernel_gid_t;
sysvipc, ncpfs, and core dumps (probably fine since they are separate
anyway),
| typedef unsigned short __kernel_old_dev_t; /* compat gets this wrong
*/
old-style loopdev ioctl
| struct stat { ... } /* possibly not needed */
- lustre ioctls (needs to be fixed anyway)
- old stat syscalls (won't be used with asm-generic/unistd.h)
| struct stat64 { ... }
- lustre ioctls
- new style stat syscalls
So, in essence the difference comes down to the syscalls for stat
and ipc. If we use the aarch32 data types, we can share the
fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
and shmctl compat system calls between aarch32-compat and
aarch64-ilp32-compat. Otherwise we have to duplicate or extend
them to cover both cases at runtime. That would be rather ugly
but entirely doable. The ioctls are hardly affected, the few
ones that differ once __kernel_long_t matches could easily be
fixed up as you say.
> I would add a variation of g):
>
> h) create a new ABI that uses asm-generic/unistd.h and generic types
> with 32-bit __kernel_long_t and 64-bit time_t. This would be POSIX
> compliant and we don't have to worry about extending time_t in the
> future. We would have to duplicate some of the generic structures
> in asm/compat.h so that we can use the compat layer. However, at
> least in the short term, we don't have an easy way to enable both
> AArch32 and AArch64 ILP32 in the same kernel (they would be
> exclusive).
I'd particularly like to avoid this case, out of pure self-interest:
> > > > However, it would be nice to get agreement on the normal 32-bit ABI
> > > > for time_t and timespec first, and then use the same thing everywhere.
> > >
> > > Do you mean for native 32-bit
Re: [PATCH v4 00/24] ILP32 for ARM64
More comments below. > On 17 Apr 2015, at 16:46, Catalin Marinas wrote: > > Even in this case, we could enable AArch32 compat knowing that ioctls > wouldn't work. If this is important, we can add an option to enable > ioctl support for ILP32 and re-target the asm/compat.h definitions. > >> g) create a new ABI that does things in exactly the way that we >> would use as the native syscall interface if we had an ilp32 >> kernel running on aarch64 with the asm-generic/unistd.h. >> This would mean a 32-bit __kernel_long_t and time_t, but extending >> time_t in the long run, together with aarch32 and i386. >> This one is particularly interesting for people that are interested >> in maximum posix compliance and in having a "nice" ABI, in particular >> if there is a slight chance that within the next decade we have >> reason to support building an arch/arm64 kernel itself in >> aarch64-ilp32 mode. I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it has full support for 64bit arithmetic anyway. I also believe that other kernel internals (e.g. filesystems and inode-numbering) would use native 64bit types. The differences on the kernel side would mainly rest in that only a 32bit address space could reasonably be managed. So a native ILP32 ABI would differ from the LP64 ABI mainly in how sizeof(long) is represented in the user-space. In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. >>> >>> Do you mean for native 32-bit architectures? I think OpenBSD uses a >>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well. >> >> Yes, and I'm working on that for Linux. The first step involves fixing >> the kernel, one file at a time, changing all users of time_t to use >> some other type (ktime_t or time64_t in most cases) instead, and introducing >> additional system calls to handle the boundary to user space without >> breaking stuff. See my presentation at >> http://elinux.org/ELC_2015_Presentations >> for more detail. > > The approach here is primarily to fix the problem for existing 32-bit > architectures by adding a new syscall and that's fine. But what if we > enforce 64-bit time_t for all _new_ architectures? This boils down to whether we can define all the new syscalls _right now_ and get the new (extended) compat-layer set up. In this case we could have a userspace implementation that already conforms to this for ILP32. Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate with everyone else. Although it feels wrong to add another ABI that has a known limitation, this may in fact be the easiest way, as any fix to ILP32 would be done together with the fixes to all other 32bit ABIs. So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks getting “some form of” ILP32 merged from resolving the 64bit time_t issue across all architectures. Phil.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Even more options below ;). I'll add mine. On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote: > Here is my current line of thinking: > > - Using all the aarch32 data structures would be the easiest way, then > we could use the side of asm-generic/unistd.h and everything should > work to the same degree as it does today for aarch32 emulation. > This means 32-bit time_t of course, and it would give us the best > tradeoff between the amount of work needed and the results we get. > A few downsides have been mentioned, but I still think it's the > best approach. This would be the approach e) that you suggested > earlier. See my comment below on point g). I don't think there are lots of similarities between the AArch32 structures and the generic ones (you can look in arch/arm/include/uapi/asm/* rather than the arm64 asm/compat.h). > - If we do not use the exact data structures that we have on aarch32, > then I think we should make aarch32 emulation and aarch64-ilp32 > emulation mutually exclusive, and provide two separate asm/compat.h > header files that contain the differences. In this case, we should > try to come up with an ABI that makes the most sense for the majority > of the use cases that people are interested in. The two most likely > choices here would be > > f) create a new ABI that follows exactly what x32 did. This is a > variation of the earlier b), c), or d), but with the change of > fixing ioctl support by using a matching asm/compat.h. This > would not be entirely POSIX compliant, but it would be a nice > hack to get the highest performance in microbenchmarks, as it > avoids most of the compat layer. Over time, it can get extended > to coexist with aarch32 emulation, but that may take a few years. Even in this case, we could enable AArch32 compat knowing that ioctls wouldn't work. If this is important, we can add an option to enable ioctl support for ILP32 and re-target the asm/compat.h definitions. > g) create a new ABI that does things in exactly the way that we > would use as the native syscall interface if we had an ilp32 > kernel running on aarch64 with the asm-generic/unistd.h. > This would mean a 32-bit __kernel_long_t and time_t, but extending > time_t in the long run, together with aarch32 and i386. > This one is particularly interesting for people that are interested > in maximum posix compliance and in having a "nice" ABI, in particular > if there is a slight chance that within the next decade we have > reason to support building an arch/arm64 kernel itself in > aarch64-ilp32 mode. I don't think there is a much difference between g) and e). The reason we re-define many structures in asm/compat.h is because we don't have a generic compat_* definition (e.g. compat_timespec, compat_timeval, compat_flock, compat_flock64; anyway, I think some of these may not even be needed with the canonical set of syscalls). The signal related structures need to be handled differently for AArch32 and AArch64-ILP32 anyway because of the difference in the register set. I would add a variation of g): h) create a new ABI that uses asm-generic/unistd.h and generic types with 32-bit __kernel_long_t and 64-bit time_t. This would be POSIX compliant and we don't have to worry about extending time_t in the future. We would have to duplicate some of the generic structures in asm/compat.h so that we can use the compat layer. However, at least in the short term, we don't have an easy way to enable both AArch32 and AArch64 ILP32 in the same kernel (they would be exclusive). > Between e), f), and g), I'd lean towards e), but I'm fine with the other > two as well and still lack sufficient information on what people want > to do with it in the long run. I guess we could wait to see a set of patches implementing e) or g) and choose between afterwards. > > > However, it would be nice to get agreement on the normal 32-bit ABI > > > for time_t and timespec first, and then use the same thing everywhere. > > > > Do you mean for native 32-bit architectures? I think OpenBSD uses a > > 64-bit time_t already on 32-bit arches, it's doable in Linux as well. > > Yes, and I'm working on that for Linux. The first step involves fixing > the kernel, one file at a time, changing all users of time_t to use > some other type (ktime_t or time64_t in most cases) instead, and introducing > additional system calls to handle the boundary to user space without > breaking stuff. See my presentation at > http://elinux.org/ELC_2015_Presentations > for more detail. The approach here is primarily to fix the problem for existing 32-bit architectures by adding a new syscall and that's fine. But what if we enforce 64-bit time_t for all _new_ architectures? -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: [PATCH v4 00/24] ILP32 for ARM64
Am 17.04.2015 um 15:17 schrieb Arnd Bergmann : > On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: > On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > There are only a few places where long should be 32bit rather than > 64bit. The non-time_t field of timespec is the only one I can think > of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new "compat" layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 >>> >>> We're basically in the same boat as x32 then, and should do the same >>> thing on both most importantly, whatever that ends up. >> >> I'm getting confused ;). I thought you were pushing for a 32-bit time_t >> on AArch64 ILP32. >> >> I'm not sure we need to be in the same boat as x32. Their decision was >> to primarily use the LP64 ABI and there are performance advantages, not >> only the 2038 issue. The downside, few POSIX incompatibilities that I >> think they are happy to live with. If we are happy to live with them as >> well, we go ahead with the current patchset. We may try to patch some of >> the POSIX incompatibilities (see Philipp's list above) by >> padding/copying/sign-extending the affected structures. > > Here is my current line of thinking: > > - Using all the aarch32 data structures would be the easiest way, then > we could use the side of asm-generic/unistd.h and everything should > work to the same degree as it does today for aarch32 emulation. > This means 32-bit time_t of course, and it would give us the best > tradeoff between the amount of work needed and the results we get. > A few downsides have been mentioned, but I still think it's the > best approach. This would be the approach e) that you suggested > earlier. > > - If we do not use the exact data structures that we have on aarch32, > then I think we should make aarch32 emulation and aarch64-ilp32 > emulation mutually exclusive, and provide two separate asm/compat.h > header files that contain the differences. In this case, we should > try to come up with an ABI that makes the most sense for the majority > of the use cases that people are interested in. The two most likely > choices here would be > > f) create a new ABI that follows exactly what x32 did. This is a > variation of the earlier b), c), or d), but with the change of > fixing ioctl support by using a matching asm/compat.h. This > would not be entirely POSIX compliant, but it would be a nice > hack to get the highest performance in microbenchmarks, as it > avoids most of the compat layer. Over time, it can get extended > to coexist with aarch32 emulation, but that may take a few years. > > g) create a new ABI that does things in exactly the way that we > would use as the native syscall interface if we had an ilp32 > kernel running on aarch64 with the asm-generic/unistd.h. > This would mean a 32-bit __kernel_long_t and time_t, but extending > time_t in the long run, together with aarch32 and i386. > This one is particularly interesting for people that are interested > in maximum posix compliance and in having a "nice" ABI, in particular > if there is a slight chance that within the next decade we have > reason to support building an arch/arm64 kernel itself in > aarch64-ilp32 mode. > > Between e), f), and g), I'd lean towards e), but I'm fine with the other > two as well and still lack sufficient information on what people want > to do with it in the long run. I agree with you here. Let's create an interface that has the least possible maintenance overhead. I personally don't care about microbenchmark results - for me the only reason ilp32 exists on aarch64 is for broken non 64bit ready code. Alex (I had to drop Catalin from CC as otherwise my mail server wouldn't let me send the mail. Hrm)-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: > > On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > > > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > > > > There are only a few places where long should be 32bit rather than > > > > 64bit. The non-time_t field of timespec is the only one I can think > > > > of. > > > > > > It may be the only one but we could end up with a non-compliant > > > timespec. Unless we keep the tv_nsec as 32-bit long and add some > > > padding, we could work around it by getting the C library to sign-extend > > > such padding or we do it in a new "compat" layer in the kernel (but both > > > cases imply copying the structure). > > > > > > However, timerspec is included in other structures, so we'd have to > > > intercept those as well. Philipp provided a list here: > > > > > > http://article.gmane.org/gmane.linux.kernel/1931497 > > > > We're basically in the same boat as x32 then, and should do the same > > thing on both most importantly, whatever that ends up. > > I'm getting confused ;). I thought you were pushing for a 32-bit time_t > on AArch64 ILP32. > > I'm not sure we need to be in the same boat as x32. Their decision was > to primarily use the LP64 ABI and there are performance advantages, not > only the 2038 issue. The downside, few POSIX incompatibilities that I > think they are happy to live with. If we are happy to live with them as > well, we go ahead with the current patchset. We may try to patch some of > the POSIX incompatibilities (see Philipp's list above) by > padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a "nice" ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. > > However, it would be nice to get agreement on the normal 32-bit ABI > > for time_t and timespec first, and then use the same thing everywhere. > > Do you mean for native 32-bit architectures? I think OpenBSD uses a > 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: > On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > > > There are only a few places where long should be 32bit rather than > > > 64bit. The non-time_t field of timespec is the only one I can think > > > of. > > > > It may be the only one but we could end up with a non-compliant > > timespec. Unless we keep the tv_nsec as 32-bit long and add some > > padding, we could work around it by getting the C library to sign-extend > > such padding or we do it in a new "compat" layer in the kernel (but both > > cases imply copying the structure). > > > > However, timerspec is included in other structures, so we'd have to > > intercept those as well. Philipp provided a list here: > > > > http://article.gmane.org/gmane.linux.kernel/1931497 > > We're basically in the same boat as x32 then, and should do the same > thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. > However, it would be nice to get agreement on the normal 32-bit ABI > for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Even more options below ;). I'll add mine. On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote: Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. See my comment below on point g). I don't think there are lots of similarities between the AArch32 structures and the generic ones (you can look in arch/arm/include/uapi/asm/* rather than the arm64 asm/compat.h). - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. Even in this case, we could enable AArch32 compat knowing that ioctls wouldn't work. If this is important, we can add an option to enable ioctl support for ILP32 and re-target the asm/compat.h definitions. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. I don't think there is a much difference between g) and e). The reason we re-define many structures in asm/compat.h is because we don't have a generic compat_* definition (e.g. compat_timespec, compat_timeval, compat_flock, compat_flock64; anyway, I think some of these may not even be needed with the canonical set of syscalls). The signal related structures need to be handled differently for AArch32 and AArch64-ILP32 anyway because of the difference in the register set. I would add a variation of g): h) create a new ABI that uses asm-generic/unistd.h and generic types with 32-bit __kernel_long_t and 64-bit time_t. This would be POSIX compliant and we don't have to worry about extending time_t in the future. We would have to duplicate some of the generic structures in asm/compat.h so that we can use the compat layer. However, at least in the short term, we don't have an easy way to enable both AArch32 and AArch64 ILP32 in the same kernel (they would be exclusive). Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. I guess we could wait to see a set of patches implementing e) or g) and choose between afterwards. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. The approach here is primarily to fix the problem for existing 32-bit architectures by adding a new syscall and that's fine. But what if we enforce 64-bit time_t for all _new_ architectures? -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Am 17.04.2015 um 15:17 schrieb Arnd Bergmann a...@arndb.de: On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. I'm getting confused ;). I thought you were pushing for a 32-bit time_t on AArch64 ILP32. I'm not sure we need to be in the same boat as x32. Their decision was to primarily use the LP64 ABI and there are performance advantages, not only the 2038 issue. The downside, few POSIX incompatibilities that I think they are happy to live with. If we are happy to live with them as well, we go ahead with the current patchset. We may try to patch some of the POSIX incompatibilities (see Philipp's list above) by padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. I agree with you here. Let's create an interface that has the least possible maintenance overhead. I personally don't care about microbenchmark results - for me the only reason ilp32 exists on aarch64 is for broken non 64bit ready code. Alex (I had to drop Catalin from CC as otherwise my mail server wouldn't let me send the mail. Hrm)-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
More comments below. On 17 Apr 2015, at 16:46, Catalin Marinas catalin.mari...@arm.com wrote: Even in this case, we could enable AArch32 compat knowing that ioctls wouldn't work. If this is important, we can add an option to enable ioctl support for ILP32 and re-target the asm/compat.h definitions. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a nice ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it has full support for 64bit arithmetic anyway. I also believe that other kernel internals (e.g. filesystems and inode-numbering) would use native 64bit types. The differences on the kernel side would mainly rest in that only a 32bit address space could reasonably be managed. So a native ILP32 ABI would differ from the LP64 ABI mainly in how sizeof(long) is represented in the user-space. In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Do you mean for native 32-bit architectures? I think OpenBSD uses a 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. The approach here is primarily to fix the problem for existing 32-bit architectures by adding a new syscall and that's fine. But what if we enforce 64-bit time_t for all _new_ architectures? This boils down to whether we can define all the new syscalls _right now_ and get the new (extended) compat-layer set up. In this case we could have a userspace implementation that already conforms to this for ILP32. Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate with everyone else. Although it feels wrong to add another ABI that has a known limitation, this may in fact be the easiest way, as any fix to ILP32 would be done together with the fixes to all other 32bit ABIs. So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks getting “some form of” ILP32 merged from resolving the 64bit time_t issue across all architectures. Phil.-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
- If we do not use the exact data structures that we have on aarch32,
then I think we should make aarch32 emulation and aarch64-ilp32
emulation mutually exclusive, and provide two separate asm/compat.h
header files that contain the differences. In this case, we should
try to come up with an ABI that makes the most sense for the majority
of the use cases that people are interested in. The two most likely
choices here would be
f) create a new ABI that follows exactly what x32 did. This is a
variation of the earlier b), c), or d), but with the change of
fixing ioctl support by using a matching asm/compat.h. This
would not be entirely POSIX compliant, but it would be a nice
hack to get the highest performance in microbenchmarks, as it
avoids most of the compat layer. Over time, it can get extended
to coexist with aarch32 emulation, but that may take a few years.
Even in this case, we could enable AArch32 compat knowing that ioctls
wouldn't work. If this is important, we can add an option to enable
ioctl support for ILP32 and re-target the asm/compat.h definitions.
We can allow them to coexist, but I'd only do that in mainline after
fixing all existing problems. Otherwise we can end up with user space
that tries to use the wrong ioctl API, and fixing the kernel breaks
the application, without a way for the kernel to detect which behavior
the user expects.
g) create a new ABI that does things in exactly the way that we
would use as the native syscall interface if we had an ilp32
kernel running on aarch64 with the asm-generic/unistd.h.
This would mean a 32-bit __kernel_long_t and time_t, but extending
time_t in the long run, together with aarch32 and i386.
This one is particularly interesting for people that are interested
in maximum posix compliance and in having a nice ABI, in particular
if there is a slight chance that within the next decade we have
reason to support building an arch/arm64 kernel itself in
aarch64-ilp32 mode.
I don't think there is a much difference between g) and e). The reason
we re-define many structures in asm/compat.h is because we don't have a
generic compat_* definition (e.g. compat_timespec, compat_timeval,
compat_flock, compat_flock64; anyway, I think some of these may not even
be needed with the canonical set of syscalls). The signal related
structures need to be handled differently for AArch32 and AArch64-ILP32
anyway because of the difference in the register set.
Interesting observation, I had not guessed this.
Let's list the differences, this is what I could find:
| #define FIOQSIZE0x545E
probably broken on arm64 already, should be investigated
| typedef unsigned short __kernel_mode_t;
| typedef unsigned short __kernel_ipc_pid_t;
Both of these affect all sysvipc, but very little else
| typedef unsigned short __kernel_uid_t;
| typedef unsigned short __kernel_gid_t;
sysvipc, ncpfs, and core dumps (probably fine since they are separate
anyway),
| typedef unsigned short __kernel_old_dev_t; /* compat gets this wrong
*/
old-style loopdev ioctl
| struct stat { ... } /* possibly not needed */
- lustre ioctls (needs to be fixed anyway)
- old stat syscalls (won't be used with asm-generic/unistd.h)
| struct stat64 { ... }
- lustre ioctls
- new style stat syscalls
So, in essence the difference comes down to the syscalls for stat
and ipc. If we use the aarch32 data types, we can share the
fstatat64, fstat64, semctl, msgsnd, msgrcv, msgctl, shmat,
and shmctl compat system calls between aarch32-compat and
aarch64-ilp32-compat. Otherwise we have to duplicate or extend
them to cover both cases at runtime. That would be rather ugly
but entirely doable. The ioctls are hardly affected, the few
ones that differ once __kernel_long_t matches could easily be
fixed up as you say.
I would add a variation of g):
h) create a new ABI that uses asm-generic/unistd.h and generic types
with 32-bit __kernel_long_t and 64-bit time_t. This would be POSIX
compliant and we don't have to worry about extending time_t in the
future. We would have to duplicate some of the generic structures
in asm/compat.h so that we can use the compat layer. However, at
least in the short term, we don't have an easy way to enable both
AArch32 and AArch64 ILP32 in the same kernel (they would be
exclusive).
I'd particularly like to avoid this case, out of pure self-interest:
However, it would be nice to get agreement on the normal 32-bit ABI
for time_t and timespec first, and then use the same thing everywhere.
Do you mean for native 32-bit architectures? I think OpenBSD uses a
64-bit time_t already on 32-bit arches, it's
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich > > wrote: > > > Just for the record (and to avoid anyone wasting their time on what’s > > > available > > > today): we are migrating this over to option (a) now, even though we would > > > prefer to see option (b) implemented. > > > > > > If we get a consensus on (b) in the next couple of days, we’ll redo > > > things for > > > option (b). If not, we will have an implementation for option (a) > > > available that > > > we can hopefully all agree on merging. > > > > I don't think either a or b are good in the long run. > > b would have been my preferred option if it wasn't for the legacy apps > support. We could also do it without much hassle in the kernel *if* we > disabled AArch32 compat support (basically use the compat layer for > ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 > should be a build time option. Right, that would be a clean way to support it, just one with a significant downside of not being able to use both ILP32 ABIs concurrently on the same system. > > There are only a few places where long should be 32bit rather than > > 64bit. The non-time_t field of timespec is the only one I can think > > of. > > It may be the only one but we could end up with a non-compliant > timespec. Unless we keep the tv_nsec as 32-bit long and add some > padding, we could work around it by getting the C library to sign-extend > such padding or we do it in a new "compat" layer in the kernel (but both > cases imply copying the structure). > > However, timerspec is included in other structures, so we'd have to > intercept those as well. Philipp provided a list here: > > http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 01:19:14PM +0200, Dr. Philipp Tomsich wrote: > Just for the record (and to avoid anyone wasting their time on what’s > available > today): we are migrating this over to option (a) now, even though we would > prefer to see option (b) implemented. > > If we get a consensus on (b) in the next couple of days, we’ll redo things for > option (b). If not, we will have an implementation for option (a) available > that > we can hopefully all agree on merging. When you post, please include the libc-alpha list (I think they are fine with cross-posting), maybe only for the cover letter as that's where the useful discussion seems to happen. It's interesting to re-read some older posts on x32 (it's not just time_t affected, though probably that the most visible): https://lwn.net/Articles/457089/ https://sourceware.org/ml/libc-alpha/2012-03/msg00487.html https://sourceware.org/ml/libc-alpha/2012-03/msg00574.html Basically for x32 POSIX compliance doesn't seem too critical. IIUC, the x32 wasn't added to solve a 32-bit compatibility problem but as a potential optimisation for specific cases. On ARM OTOH, (one of?) the main goal for AArch64 ILP32 is to offer a solution for 32-bit code when AArch32 is not present (and potentially slightly more optimal than AArch32 but not necessarily when compared to LP64). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich > wrote: > > Just for the record (and to avoid anyone wasting their time on what’s > > available > > today): we are migrating this over to option (a) now, even though we would > > prefer to see option (b) implemented. > > > > If we get a consensus on (b) in the next couple of days, we’ll redo things > > for > > option (b). If not, we will have an implementation for option (a) available > > that > > we can hopefully all agree on merging. > > I don't think either a or b are good in the long run. b would have been my preferred option if it wasn't for the legacy apps support. We could also do it without much hassle in the kernel *if* we disabled AArch32 compat support (basically use the compat layer for ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 should be a build time option. > There are only a few places where long should be 32bit rather than > 64bit. The non-time_t field of timespec is the only one I can think > of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new "compat" layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 > The rest are valid and good idea to stay as 64bit. Including the > limits. I think this whole discussion should have happened over a year > ago. And I thought c was decided back then. I had even implemented a > originally and then asked to move over to c. So I am a bit upset now > we are making this kind of huge changes to the abi a year after the > original posting of the patch. Well, I said it already, this ABI is *not* a kernel-only decision, so without further feedback from the user space world I'm not merging any patches. I thought I was pretty clear 6-7 months ago but there wasn't any reply until February: http://article.gmane.org/gmane.linux.kernel/185 > Also why does it takes over a year to accept patches into the linux > kernel when it takes much less time to make huge changes into gcc Original developers being unresponsive could be a reason ;) (see the above post unanswered for few months). > (pointer plus is an example which took only a few months to accept and > it was an infrastructure change and this is not even an infrastructure > change). ILP32 is an ABI that we have to leave with for many years. We have to try hard to get it right rather than rush merging the patches (once merged, we can't break the ABI later). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
> On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich > wrote: > > Just for the record (and to avoid anyone wasting their time on what’s > available > today): we are migrating this over to option (a) now, even though we would > prefer to see option (b) implemented. > > If we get a consensus on (b) in the next couple of days, we’ll redo things for > option (b). If not, we will have an implementation for option (a) available > that > we can hopefully all agree on merging. I don't think either a or b are good in the long run. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch. Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change). Thanks, Andrew > > Best, > Phil. > >> On 16 Apr 2015, at 13:03, Catalin Marinas wrote: >> >> On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >>> We've just started to bootstrap openSUSE for ILP32 with the non-final >>> abi. However, keep in mind that at least for us bootstrapping is a >>> manual process. So changing syscall numbers means we'll need to go >>> through the manual process again. >>> >>> So if you need any help on getting you an environment that allows you to >>> build LTP with whatever syscall abi people come up with, feel free to >>> poke Andreas or me. >> >> Thanks for the offer. It's great to see a full distro being built (even >> though no commitment). >> >> But I'm a bit worried that people started using these patches and we >> haven't agreed on the ABI yet (well, for a while we thought that the x32 >> approach was fine until I've seen objections from others). >> >> Maybe a quick poll on the options, ignoring syscall number details (we >> go for the generic ones) or syscall tables sharing: >> >> a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t >> (POSIX-compliant) >> b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as >> seen by the user) (POSIX-compliant) >> c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t >> (non-POSIX-compliant) >> >> Option (a) is the easiest from the kernel perspective and has the >> highest chance of not breaking legacy AArch32 applications. >> >> Option (b) is more future looking (beyond 2038) but it introduces a >> third ABI in the kernel (incompatible with both compat and native). >> There is also a risk that legacy applications assume a 32-bit time_t. >> >> Option (c) is pretty much what we currently have in these patches. While >> many syscalls are native LP64, it doesn't fully solve pointers in >> structures shared between user and kernel (ioctl being one of the >> affected areas) >> >> I can't tell how bad the impact of non-POSIX compliance is. If this is >> essential, between (a) and (b) I'm more in favour of (a) as the easiest >> for both kernel and user. If we were to start a new ABI from scratch >> without legacy applications, I would have definitely gone for (b) but >> I'm worried about legacy applications still not fully working with this >> option while adding more maintenance burden in the kernel. >> >> -- >> Catalin > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. Best, Phil. > On 16 Apr 2015, at 13:03, Catalin Marinas wrote: > > On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >> We've just started to bootstrap openSUSE for ILP32 with the non-final >> abi. However, keep in mind that at least for us bootstrapping is a >> manual process. So changing syscall numbers means we'll need to go >> through the manual process again. >> >> So if you need any help on getting you an environment that allows you to >> build LTP with whatever syscall abi people come up with, feel free to >> poke Andreas or me. > > Thanks for the offer. It's great to see a full distro being built (even > though no commitment). > > But I'm a bit worried that people started using these patches and we > haven't agreed on the ABI yet (well, for a while we thought that the x32 > approach was fine until I've seen objections from others). > > Maybe a quick poll on the options, ignoring syscall number details (we > go for the generic ones) or syscall tables sharing: > > a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t > (POSIX-compliant) > b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as > seen by the user) (POSIX-compliant) > c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t > (non-POSIX-compliant) > > Option (a) is the easiest from the kernel perspective and has the > highest chance of not breaking legacy AArch32 applications. > > Option (b) is more future looking (beyond 2038) but it introduces a > third ABI in the kernel (incompatible with both compat and native). > There is also a risk that legacy applications assume a 32-bit time_t. > > Option (c) is pretty much what we currently have in these patches. While > many syscalls are native LP64, it doesn't fully solve pointers in > structures shared between user and kernel (ioctl being one of the > affected areas) > > I can't tell how bad the impact of non-POSIX compliance is. If this is > essential, between (a) and (b) I'm more in favour of (a) as the easiest > for both kernel and user. If we were to start a new ABI from scratch > without legacy applications, I would have definitely gone for (b) but > I'm worried about legacy applications still not fully working with this > option while adding more maintenance burden in the kernel. > > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: > We've just started to bootstrap openSUSE for ILP32 with the non-final > abi. However, keep in mind that at least for us bootstrapping is a > manual process. So changing syscall numbers means we'll need to go > through the manual process again. > > So if you need any help on getting you an environment that allows you to > build LTP with whatever syscall abi people come up with, feel free to > poke Andreas or me. Thanks for the offer. It's great to see a full distro being built (even though no commitment). But I'm a bit worried that people started using these patches and we haven't agreed on the ABI yet (well, for a while we thought that the x32 approach was fine until I've seen objections from others). Maybe a quick poll on the options, ignoring syscall number details (we go for the generic ones) or syscall tables sharing: a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t (POSIX-compliant) b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as seen by the user) (POSIX-compliant) c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t (non-POSIX-compliant) Option (a) is the easiest from the kernel perspective and has the highest chance of not breaking legacy AArch32 applications. Option (b) is more future looking (beyond 2038) but it introduces a third ABI in the kernel (incompatible with both compat and native). There is also a risk that legacy applications assume a 32-bit time_t. Option (c) is pretty much what we currently have in these patches. While many syscalls are native LP64, it doesn't fully solve pointers in structures shared between user and kernel (ioctl being one of the affected areas) I can't tell how bad the impact of non-POSIX compliance is. If this is essential, between (a) and (b) I'm more in favour of (a) as the easiest for both kernel and user. If we were to start a new ABI from scratch without legacy applications, I would have definitely gone for (b) but I'm worried about legacy applications still not fully working with this option while adding more maintenance burden in the kernel. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: We've just started to bootstrap openSUSE for ILP32 with the non-final abi. However, keep in mind that at least for us bootstrapping is a manual process. So changing syscall numbers means we'll need to go through the manual process again. So if you need any help on getting you an environment that allows you to build LTP with whatever syscall abi people come up with, feel free to poke Andreas or me. Thanks for the offer. It's great to see a full distro being built (even though no commitment). But I'm a bit worried that people started using these patches and we haven't agreed on the ABI yet (well, for a while we thought that the x32 approach was fine until I've seen objections from others). Maybe a quick poll on the options, ignoring syscall number details (we go for the generic ones) or syscall tables sharing: a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t (POSIX-compliant) b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as seen by the user) (POSIX-compliant) c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t (non-POSIX-compliant) Option (a) is the easiest from the kernel perspective and has the highest chance of not breaking legacy AArch32 applications. Option (b) is more future looking (beyond 2038) but it introduces a third ABI in the kernel (incompatible with both compat and native). There is also a risk that legacy applications assume a 32-bit time_t. Option (c) is pretty much what we currently have in these patches. While many syscalls are native LP64, it doesn't fully solve pointers in structures shared between user and kernel (ioctl being one of the affected areas) I can't tell how bad the impact of non-POSIX compliance is. If this is essential, between (a) and (b) I'm more in favour of (a) as the easiest for both kernel and user. If we were to start a new ABI from scratch without legacy applications, I would have definitely gone for (b) but I'm worried about legacy applications still not fully working with this option while adding more maintenance burden in the kernel. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. Best, Phil. On 16 Apr 2015, at 13:03, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: We've just started to bootstrap openSUSE for ILP32 with the non-final abi. However, keep in mind that at least for us bootstrapping is a manual process. So changing syscall numbers means we'll need to go through the manual process again. So if you need any help on getting you an environment that allows you to build LTP with whatever syscall abi people come up with, feel free to poke Andreas or me. Thanks for the offer. It's great to see a full distro being built (even though no commitment). But I'm a bit worried that people started using these patches and we haven't agreed on the ABI yet (well, for a while we thought that the x32 approach was fine until I've seen objections from others). Maybe a quick poll on the options, ignoring syscall number details (we go for the generic ones) or syscall tables sharing: a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t (POSIX-compliant) b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as seen by the user) (POSIX-compliant) c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t (non-POSIX-compliant) Option (a) is the easiest from the kernel perspective and has the highest chance of not breaking legacy AArch32 applications. Option (b) is more future looking (beyond 2038) but it introduces a third ABI in the kernel (incompatible with both compat and native). There is also a risk that legacy applications assume a 32-bit time_t. Option (c) is pretty much what we currently have in these patches. While many syscalls are native LP64, it doesn't fully solve pointers in structures shared between user and kernel (ioctl being one of the affected areas) I can't tell how bad the impact of non-POSIX compliance is. If this is essential, between (a) and (b) I'm more in favour of (a) as the easiest for both kernel and user. If we were to start a new ABI from scratch without legacy applications, I would have definitely gone for (b) but I'm worried about legacy applications still not fully working with this option while adding more maintenance burden in the kernel. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich philipp.toms...@theobroma-systems.com wrote: Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. I don't think either a or b are good in the long run. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch. Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change). Thanks, Andrew Best, Phil. On 16 Apr 2015, at 13:03, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: We've just started to bootstrap openSUSE for ILP32 with the non-final abi. However, keep in mind that at least for us bootstrapping is a manual process. So changing syscall numbers means we'll need to go through the manual process again. So if you need any help on getting you an environment that allows you to build LTP with whatever syscall abi people come up with, feel free to poke Andreas or me. Thanks for the offer. It's great to see a full distro being built (even though no commitment). But I'm a bit worried that people started using these patches and we haven't agreed on the ABI yet (well, for a while we thought that the x32 approach was fine until I've seen objections from others). Maybe a quick poll on the options, ignoring syscall number details (we go for the generic ones) or syscall tables sharing: a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t (POSIX-compliant) b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as seen by the user) (POSIX-compliant) c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t (non-POSIX-compliant) Option (a) is the easiest from the kernel perspective and has the highest chance of not breaking legacy AArch32 applications. Option (b) is more future looking (beyond 2038) but it introduces a third ABI in the kernel (incompatible with both compat and native). There is also a risk that legacy applications assume a 32-bit time_t. Option (c) is pretty much what we currently have in these patches. While many syscalls are native LP64, it doesn't fully solve pointers in structures shared between user and kernel (ioctl being one of the affected areas) I can't tell how bad the impact of non-POSIX compliance is. If this is essential, between (a) and (b) I'm more in favour of (a) as the easiest for both kernel and user. If we were to start a new ABI from scratch without legacy applications, I would have definitely gone for (b) but I'm worried about legacy applications still not fully working with this option while adding more maintenance burden in the kernel. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich philipp.toms...@theobroma-systems.com wrote: Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. I don't think either a or b are good in the long run. b would have been my preferred option if it wasn't for the legacy apps support. We could also do it without much hassle in the kernel *if* we disabled AArch32 compat support (basically use the compat layer for ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 should be a build time option. Right, that would be a clean way to support it, just one with a significant downside of not being able to use both ILP32 ABIs concurrently on the same system. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich philipp.toms...@theobroma-systems.com wrote: Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. I don't think either a or b are good in the long run. b would have been my preferred option if it wasn't for the legacy apps support. We could also do it without much hassle in the kernel *if* we disabled AArch32 compat support (basically use the compat layer for ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 should be a build time option. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new compat layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch. Well, I said it already, this ABI is *not* a kernel-only decision, so without further feedback from the user space world I'm not merging any patches. I thought I was pretty clear 6-7 months ago but there wasn't any reply until February: http://article.gmane.org/gmane.linux.kernel/185 Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc Original developers being unresponsive could be a reason ;) (see the above post unanswered for few months). (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change). ILP32 is an ABI that we have to leave with for many years. We have to try hard to get it right rather than rush merging the patches (once merged, we can't break the ABI later). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Thu, Apr 16, 2015 at 01:19:14PM +0200, Dr. Philipp Tomsich wrote: Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. When you post, please include the libc-alpha list (I think they are fine with cross-posting), maybe only for the cover letter as that's where the useful discussion seems to happen. It's interesting to re-read some older posts on x32 (it's not just time_t affected, though probably that the most visible): https://lwn.net/Articles/457089/ https://sourceware.org/ml/libc-alpha/2012-03/msg00487.html https://sourceware.org/ml/libc-alpha/2012-03/msg00574.html Basically for x32 POSIX compliance doesn't seem too critical. IIUC, the x32 wasn't added to solve a 32-bit compatibility problem but as a potential optimisation for specific cases. On ARM OTOH, (one of?) the main goal for AArch64 ILP32 is to offer a solution for 32-bit code when AArch32 is not present (and potentially slightly more optimal than AArch32 but not necessarily when compared to LP64). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On 15.04.15 19:22, Catalin Marinas wrote: > On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote: >> On 15 Apr 2015, at 17:38, Catalin Marinas wrote: >>> On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: >> We’ve run full systems (built from buildroot) consisting of ILP32 >> binaries >> only (ok… admittedly gdb was an exception, as we haven’t fixed the fact >> that someone has assumed sizeof(long) == 8 in some data-structure of >> the AArch64 backend there) in our verification runs. In fact, it will be >> very >> special classes of applications that will need a 64bit address-space. > > If we are to merge AArch64-ILP32, I'd like to see a full software stack, > maybe a distro like Debian. Otherwise the kernel code will bit-rot (just > like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. >>> >>> I agree with this not being a prerequisite for merging ILP32 but at >>> least a long term plan to do something beyond openembedded, once we >>> agreed on the ABI and _upstreamed_ the kernel and glibc code. Those >>> legacy applications will probably need more than glibc to run and it's >>> likely that people will want to run them in a full AArch64 (LP64) >>> environment. A simpler approach (to me, I'm not a distro person) would >>> be to just provide additional ILP32 libs in a multi-lib arm64 distro >>> like Debian rather than all the packages. As for the compiler, AFAIK >>> aarch64-linux-gnu-* simply needs an option to build for ILP32. >> >> We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, >> termcap, zlib and a few others in a multiarch setup… this was used in the >> field by customers and worked rather well. >> >> One of the engineers in my team is currently working on carrying this forward >> so we can use this for any Debian-based AArch64 distribution in the future. > > That sounds great. What I'm looking for is to be able to build something > like LTP to be able to reproduce the testing before merging the code. So > the PPA approach looks good. We've just started to bootstrap openSUSE for ILP32 with the non-final abi. However, keep in mind that at least for us bootstrapping is a manual process. So changing syscall numbers means we'll need to go through the manual process again. So if you need any help on getting you an environment that allows you to build LTP with whatever syscall abi people come up with, feel free to poke Andreas or me. Alex PS: This mail does not include any commitment to maintain an ILP32 openSUSE distribution ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote: > On 15 Apr 2015, at 17:38, Catalin Marinas wrote: > > On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: > >> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: > >>> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: > We’ve run full systems (built from buildroot) consisting of ILP32 > binaries > only (ok… admittedly gdb was an exception, as we haven’t fixed the fact > that someone has assumed sizeof(long) == 8 in some data-structure of > the AArch64 backend there) in our verification runs. In fact, it will be > very > special classes of applications that will need a 64bit address-space. > >>> > >>> If we are to merge AArch64-ILP32, I'd like to see a full software stack, > >>> maybe a distro like Debian. Otherwise the kernel code will bit-rot (just > >>> like it regularly happens with big endian). > >> > >> I actually don't think this should be a prerequisite. We have too many > >> dependencies here, and as long as we are debating the exact ABI, > >> any work that gets put into a full distro support (other than openembedded > >> etc) would likely be wasted. > > > > I agree with this not being a prerequisite for merging ILP32 but at > > least a long term plan to do something beyond openembedded, once we > > agreed on the ABI and _upstreamed_ the kernel and glibc code. Those > > legacy applications will probably need more than glibc to run and it's > > likely that people will want to run them in a full AArch64 (LP64) > > environment. A simpler approach (to me, I'm not a distro person) would > > be to just provide additional ILP32 libs in a multi-lib arm64 distro > > like Debian rather than all the packages. As for the compiler, AFAIK > > aarch64-linux-gnu-* simply needs an option to build for ILP32. > > We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, > termcap, zlib and a few others in a multiarch setup… this was used in the > field by customers and worked rather well. > > One of the engineers in my team is currently working on carrying this forward > so we can use this for any Debian-based AArch64 distribution in the future. That sounds great. What I'm looking for is to be able to build something like LTP to be able to reproduce the testing before merging the code. So the PPA approach looks good. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 15 Apr 2015, at 17:38, Catalin Marinas wrote: > > On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: >> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: >>> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. >>> >>> If we are to merge AArch64-ILP32, I'd like to see a full software stack, >>> maybe a distro like Debian. Otherwise the kernel code will bit-rot (just >>> like it regularly happens with big endian). >> >> I actually don't think this should be a prerequisite. We have too many >> dependencies here, and as long as we are debating the exact ABI, >> any work that gets put into a full distro support (other than openembedded >> etc) would likely be wasted. > > I agree with this not being a prerequisite for merging ILP32 but at > least a long term plan to do something beyond openembedded, once we > agreed on the ABI and _upstreamed_ the kernel and glibc code. Those > legacy applications will probably need more than glibc to run and it's > likely that people will want to run them in a full AArch64 (LP64) > environment. A simpler approach (to me, I'm not a distro person) would > be to just provide additional ILP32 libs in a multi-lib arm64 distro > like Debian rather than all the packages. As for the compiler, AFAIK > aarch64-linux-gnu-* simply needs an option to build for ILP32. We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, termcap, zlib and a few others in a multiarch setup… this was used in the field by customers and worked rather well. One of the engineers in my team is currently working on carrying this forward so we can use this for any Debian-based AArch64 distribution in the future. Best, Phil. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote: > On 15 Apr 2015, at 13:22, Catalin Marinas wrote: > > I think you are right. I was more thinking of those routed directly to > > the native (non-compat) syscalls. We would need to make sure the return > > value (X0 being the only register not restored on return from exception) > > has the top 32-bit part zeroed. > > As the kernel is LP64 and will thus attempt to return a 64bit return value, > the > high bits should be properly sign-extended in all cases. > > The problem (posed by procedure call standard) of information leakage could > manifest itself only, if the kernel tried to return something smaller than 64 > bits… > in that case, we can the problem would already exhibit for the LP64 ABI. > > For the ILP32 implementation, I’ll thus assume that all LP64 ABI calls reused > are clean in this regard. Yes. All the compat_sys_* are defined to return a long, so even if ILP32 user space treats it as 32-bit, there is no information leak because of the kernel's sign-extension. So just a false alarm, we can consider this part sorted. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: > On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: > > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: > > > We’ve run full systems (built from buildroot) consisting of ILP32 binaries > > > only (ok… admittedly gdb was an exception, as we haven’t fixed the fact > > > that someone has assumed sizeof(long) == 8 in some data-structure of > > > the AArch64 backend there) in our verification runs. In fact, it will be > > > very > > > special classes of applications that will need a 64bit address-space. > > > > If we are to merge AArch64-ILP32, I'd like to see a full software stack, > > maybe a distro like Debian. Otherwise the kernel code will bit-rot (just > > like it regularly happens with big endian). > > I actually don't think this should be a prerequisite. We have too many > dependencies here, and as long as we are debating the exact ABI, > any work that gets put into a full distro support (other than openembedded > etc) would likely be wasted. I agree with this not being a prerequisite for merging ILP32 but at least a long term plan to do something beyond openembedded, once we agreed on the ABI and _upstreamed_ the kernel and glibc code. Those legacy applications will probably need more than glibc to run and it's likely that people will want to run them in a full AArch64 (LP64) environment. A simpler approach (to me, I'm not a distro person) would be to just provide additional ILP32 libs in a multi-lib arm64 distro like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. > > > The key question at this point seems to be whether we want to support > > > “legacy 32-bit applications” (i.e. ones that make assumption that are > > > not covered by the underlying type definitions or specifications) or > > > whether > > > we aim for “well-formed 32-bit applications”. > > > > > > To stay with the 'struct timespec’-example, the difference between the > > > former and the latter would (among others) be that the former might > > > assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to > > > except that sizeof(long) == sizeof(ts.tv_nsec). > > > > > > I don’t believe in keeping compatibility for the former type of > > > applications. > > > > That was one of the initial reasons I heard for AArch64-ILP32. So more > > mixed messages. > > Of course you hear different stories from different people, and some of > them might just be asking for things they don't fully understand. > > As far as I'm concerned, supporting broken legacy applications in the > *only* reason we should be doing this for. If people are asking for > it "because x86 does it", "for performance" or "because it lines up > nicely with what the toolchain can do", I'm more than happy to ignore > them. I'm not even debating this for the lack of market feedback. So I tend to agree with you. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: > > On 15 Apr 2015, at 00:28, Arnd Bergmann wrote: > > > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: > > >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: > > >>> For completeness, there is yet another option, which would be to use the > > >>> exact system call table from arm64 and do all the emulation in user > > >>> space > > >>> rather than the kernel. This would however be the least compatible with > > >>> existing source code, so you probably don't want to do that. > > >> > > >> It would be great if this worked but I think we looked at it before and > > >> it seems nice until you hit the futex stuff and robust lists (I don't > > >> fully remember the details). Some of the structures (siginfo) would no > > >> longer be POSIX compliant and some of them aren't only accessed via libc > > >> to be able to create shadow copies. > > > > > > Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to > > > enable a very special class of applications, it's not like anyone would > > > want to run a full system for this and need POSIX compliance. > > > > I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 > > ecosystem as a “data-model” for AArch64. Having a corresponding Linux > > syscall ABI is necessitated because not all data structures shared across > > the syscall-boundary are describted/defined in data-model agnostic types. > > ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus > > neither a hack nor likely/expected to go away anytime soon. > > That's the kind of feedback I've been trying to get from the software > ecosystem - whether AArch64-ILP32 is a temporary hack for legacy 32-bit > applications or a solid long term solution for those not needing 64-bit. > The benchmarks I've seen so far didn't show any significant improvement > of AArch64-ILP32 over LP64. The comparison with AArch32 may not be > entirely fair at the moment due to the maturity of AArch64-ILP32 > toolchains but I don't think we'll see a big jump. > > The messages I get are mixed, even from companies initially stating the > need for ILP32. So I can't make an informed decision but I think we > should go for the safer option: a first class citizen, long term ABI. It > costs more in (kernel) maintenance initially but if it happens to catch > on, it will cost us later. The alternative is not to bother with > AArch64-ILP32 at all, especially if it's going to be used only as a > marketing exercise for CPUs not supporting AArch32. Agreed on all this. > (if anyone has more feedback on commercial needs for ILP32, please let > us know, even if it is in private) > > > We’ve run full systems (built from buildroot) consisting of ILP32 binaries > > only (ok… admittedly gdb was an exception, as we haven’t fixed the fact > > that someone has assumed sizeof(long) == 8 in some data-structure of > > the AArch64 backend there) in our verification runs. In fact, it will be > > very > > special classes of applications that will need a 64bit address-space. > > If we are to merge AArch64-ILP32, I'd like to see a full software stack, > maybe a distro like Debian. Otherwise the kernel code will bit-rot (just > like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. > > > We could definitely be pragmatic and do whatever helps get the job > > > done. That said, it diverges further from what legacy 32-bit applications > > > expect to see, so this approach will likely make an application port > > > harder, > > > not easier. > > > > The key question at this point seems to be whether we want to support > > “legacy 32-bit applications” (i.e. ones that make assumption that are > > not covered by the underlying type definitions or specifications) or whether > > we aim for “well-formed 32-bit applications”. > > > > To stay with the 'struct timespec’-example, the difference between the > > former and the latter would (among others) be that the former might > > assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to > > except that sizeof(long) == sizeof(ts.tv_nsec). > > > > I don’t believe in keeping compatibility for the former type of > > applications. > > That was one of the initial reasons I heard for AArch64-ILP32. So more > mixed messages. Of course you hear different stories from different people, and some of them might just be asking for things they don't fully understand. As far as I'm concerned, supporting broken legacy applications in the *only* reason we should be doing this for. If people are asking for it "because x86 does it", "for performance" or "because it lines up nicely with
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 17:55:00 Catalin Marinas wrote: > On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote: > > So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C > > language. Any program that assumes that tv_nsec is sizeof(long) would be > > correct and it would be unexpected and surprising behaviour [even though it > > would be consider a good programming style] if one would need to explicitly > > ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem > > like a good justification to do the same. > > From a standards perspective, that's clear, and I'm fine with not making > the same choice as x32. I think on x32 it was a side-effect of glibc > defining tv_nsec as __syscall_slong_t and the kernel defining > __kernel_long_t to 64-bit. I'm pretty sure that this part of the x32 ABI was a deliberate choice in full knowledge of the tradeoffs. > > For time_t, I don’t see the need to have a 32bit type yet. > > As long as the the type is properly exposed through header files (and user > > programs can thus recreate the kernel’s data model), we should be safe. > > The problem with a 64-bit time_t is that the timespec structure looks > like neither compat32 nor native 64-bit. If we make the AArch32 and > native ILP32 exclusive and build time, it makes it easier, otherwise we > need to support a third ABI in the kernel. Exactly, which is why the layout was chosen to be the same as x86-64 for x32. > > Can we thus agree on the following for the next revision of the patch-set: > > (1) We retain a 64bit time_t, but implement different sizes (between ILP32 > > and > > LP64) for ‘tv_nsec' in 'struct timespec’? > > (2) We use the 64bit system calls whereever possible (i.e. no register > > splitting). > > As I mentioned above, timespec and possibly other structures no longer > like any of the existing ABIs. Do we know how many syscalls are > affected? > > The alternative is 32-bit time_t which makes it easier to use the compat > syscall implementations (not numbers). It also depends on how we plan to > fix the 2038 problem. For new 32-bit only architectures, are we going to > require them to use a 64-bit time_t or we get alternative time64_t and > timespec64 specs? No, we had originally planned that a few years ago, but after deciding that we are fixing this problem for all 32-bit machines, and also seeing the magnitude of changes involved in that, I think we have a general consensus that we do not want to add special cases for architectures that use 64-bit time_t before everyone else does. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote:
>
> > On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
> >
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and
> >> ioctls:
> >> we have many drivers that today use ioctls with data structures derived
> >> from
> >> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
> >> their own data structures. These are almost all broken today, because the
> >> data structures are a mix of the aarch32 and aarch64 variants, while the
> >> ioctl() system call in ilp32 always uses the aarch32 format by default.
> >>
> >> An example here would be
> >>
> >> struct cyclades_idle_stats {
> >>__kernel_time_t in_use; /* Time device has been in use (secs) */
> >>__kernel_time_t recv_idle; /* Time since last char received (secs) */
> >>__kernel_time_t xmit_idle; /* Time since last char transmitted (secs)
> >> */
> >>unsigned long recv_bytes; /* Bytes received */
> >>unsigned long xmit_bytes; /* Bytes transmitted */
> >>unsigned long overruns;/* Input overruns */
> >>unsigned long frame_errs; /* Input framing errors */
> >>unsigned long parity_errs; /* Input parity errors */
> >> };
> >>
> >> for a random ancient driver. Introducing a third set of data structures
> >> and syscalls for aarch64-ilp32 means that any driver doing something like
> >> this needs to be modified to support existing user space source code.
> >
> > That's indeed a problem as ILP32 doesn't look like any of the other
> > options (the siginfo structure is another case that doesn't fit in any
> > of the ABI as long as time_t is 64-bit).
>
> I believe we’ve already arrived at the conclusion that timespec needs to be
> changed from what Andrew and I had submitted.
>
> Let’s go back to the underlying definition of timespec:
> "The range and precision of times representable in clock_t and time_t
> are
> implementation-defined. The timespec structure shall contain at least
> the
>following members, in any order.
>
>time_t tv_sec; // whole seconds -- >= 0
>long tv_nsec; // nanoseconds -- [0, 9]”
>
> So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
> language. Any program that assumes that tv_nsec is sizeof(long) would be
> correct and it would be unexpected and surprising behaviour [even though it
> would be consider a good programming style] if one would need to explicitly
> ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
> like a good justification to do the same.
I don't think assuming that people who don't write 64-bit safe code
write code that follows C11 is realistic ;-)
A lot more code is broken by having a 64-bit time_t than would be
broken by making tv_nsec 64-bit.
> For time_t, I don’t see the need to have a 32bit type yet.
> As long as the the type is properly exposed through header files (and user
> programs can thus recreate the kernel’s data model), we should be safe.
>
> Cases like the above data structure from an ioctl are clearly non-portable
> and would break today on any architecture that supports ABIs with different
> data models (say ILP32 and LP64)… so I would consider any attempt to
> support this as trying to remain “bug-compatible”.
>
> There are plenty of good examples in the uapi that will be nicely portable
> between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this,
> as the userspace library libaio uses a broken redefinition instead of the
> kernel header file) as an example:
> > /*
> > ...
structures that done in modern times by competent developers should all
be the same across the three ABIs, no need to worry about that.
The only worrying part is drivers that are written in an incompatible
form for whatever reason. These have become rarer in the recent years,
but we still see new ones getting merged, e.g. the Android binder.
> The key to any design decision should be that we
> (a) don’t break C11, POSIX or the Single UNIX Specification
> (b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
> (which defines 64bit values transferable in registers to callees)
These are nice goals, but I don't think they primary objectives.
Getting things to work is much more important, and the timespec
definition among other things may end up not being standards compliant
in order to get there.
> Can we thus agree on the following for the next revision of the patch-set:
> (1) We retain a 64bit time_t, but implement different sizes (between ILP32
> and
> LP64) for ‘tv_nsec' in 'struct timespec’?
I have a plan for addressing that, but it will likely take another year
before we can get consensus on the timespec layout for 64-bit time_t.
At the moment, it looks like the 64/64 layout has more support than the
64/pad/32 layout you are describing. Let's not rush this for aarch64
when there is a
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 16:54:22 Dr. Philipp Tomsich wrote: > On 14 Apr 2015, at 16:07, Arnd Bergmann wrote: > > > > I don't understand what you mean here, please elaborate. Why would an ABI > > that works > > on aarch32 be wrong on aarch64-ilp32 user space when you are using the same > > header > > files? > AArch32 and AArch64/ILP32 are entirely different instruction set > architectures. They have > differently sized register files (AArch64 has about twice as many registers > and each one is > 64bits in size) and different register usage conventions. > > This affects other “implementation details” such as the ucontext, too. > For the sake of simplicity, I’ll refer to it just as “register file” below. > > This means that we would end up with very distinct code paths for the > “dependent” in tools > (such as strace), if option (d) was used: > LP64: AArch64 context + 64bit syscall interface > ILP32: AArch64 context + 32bit syscall interface > AArch32:AArch32 context + 32bit syscall interface > > If we could agree on option (b), things would be much simpler: > LP64: AArch64 context + 64bit syscall interface > ILP32: AArch64 context + 64bit syscall interface + ILP32 > compat-syscalls > AArch32:AArch32 context + 32bit syscall interface > > I.e. for all tools involved (whether it’s strace, gdb, etc.), LP64 and ILP32 > can and should > look very similar. After all, they differ in their sizeof(ptr_t) and > sizeof(long), only. > AArch32, on the other hand, is very dissimilar to AArch64… it’s a different > architecture. > > But this is talking from a tools-perspective... Ok, I see. >From the kernel perspective, this is very different: The compat syscall handling in the kernel is fixed to the aarch32 behavior, and in particular ioctl (but also a few others) in the current patch set need to share that syscall between both IPL32 implementations (you can't use the LP64 version). This means any data structure that can get passed into ioctl needs to share the exact same layout between all ILP32 ABIs, or it would be a bug in the kernel until someone fixes the driver to handle all three data structure formats. I thought until today that this would be limited to ioctl arguments derived from the __kernel_ulong_t derived types I mentioned (__kernel_size_t, __kernel_time_t, __kernel_ptrdiff_t, __kernel_off_t, __kernel_clock_t, __kernel_ino_t, ...), but the problem is actually bigger than that and also concerns types that are different between the traditional arm32 types and the widened asm-generic types (__kernel_uid_t, __kernel_gid_t, __kernel_mode_t, __kernel_off_t, __kernel_ipc_pid_t). If we use the generic definitions for all those types, we cannot use the existing compat_sys_ioctl() system call. If we use the aarch32 definitions, we also have to use the other compat_sys_* calls that aarch32 uses in place of the native ones (though a lot of syscalls are not needed any more in general). Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 05:44:07PM +0200, Arnd Bergmann wrote: > On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote: > > On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote: > > > 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 > > > > IMO, (d) only makes sense if we treat ILP32 as a temporary solution > > (a.k.a. hack) hoping that such applications will be eventually built for > > LP64. If we treat native ILP32 as a real long term alternative to LP64, > > I would rather use the asm-generic/unistd.h for syscalls. For example, > > use 'openat' instead of 'open' on the native ILP32 (based on the > > assumption that ILP32 is a long term alternative). > > > > Unless we are aware of performance impact with (a), that's my preferred > > option with some form of (b) next. > > Ok, let's call that option > > e) Use the existing aarch32 data structures with the asm-generic/unistd.h > system call numbers. > > This would solve the main problem of the data structures just like option > d), and the main user-visible change would be that the syscall numbers > are shifted compared to aarch32, which is a very minor aspect. We could > also deal with the ucontext better this way than what I suggested. I think that's the easiest from a kernel perspective. But see the other sub-thread on the long term view of ILP32 (beyond 2038). > > The above is mainly about syscall numbers and tables but the ABI goes > > beyond this. And the key point is whether we go for an AArch32-like ABI > > (32-bit time_t) or we try to define one close to LP64. If we go for an > > AArch32-like ABI, we'll have to use the compat layer for some of > > syscalls and assess how many of the asm/compat.h structures are > > different from the generic ones (I wouldn't expect many). > > It would be wildly different from the generic data structures, since we > can only use the compat code if the implementation is the same as on > aarch32. Essentially we have to define the headers so that all native > data structures match what is in arch/arm64/include/asm/compat.h, > which in turn is largely the same as arch/arm/include/uapi/asm/*.h. What I meant by generic structures is those include/uapi/asm-generic/*.h structures but compiled in an ILP32 context (exported headers not as they are compiled in the LP64 kernel). Many of the asm/compat.h had to be defined so that we can build them in the kernel context but many of them are the same as the asm-generic ones (when compiled as ILP32). BTW, we have to sort out the exported headers as well since we can't rely on AArch32 for this. In the kernel, we'll have to re-use asm/compat.h or some other asm/ilp32.h. > > > Finally, there is a certain set of security issues from each new syscall > > > we introduce. With the aarch32 syscall table, we have a higher degree > > > of reuse of existing code, so we won't introduce security bugs that > > > are only in one of the two ilp32 ABIs (aarch32 and aarch64). > > > > Note that the current aarch32 compat ABI assumes that the top 32-bit of > > every register is either zeroed or preserved by the architecture on > > exception entry. We know that an AArch32 application cannot access the > > top 32-bit of an AArch64 register. With native ILP32 however this is no > > longer the case (it is running in AArch64 mode). I can't immediately > > think of a problem (information leak) but it needs to be reviewed. > > Hmm, interesting point. I'd have to think about this a bit more, but > I believe it is already solved: > > - For input arguments, we have the COMPAT_SYSCALL_DEFINE wrappers that > are meant to deal with this problem. > - For output arguments, the kernel controls the register contents, > and I don't see a way that the function return value could leak > data in the upper bits. All syscall return 'long', so it should > be well-defined. I think you are right. I was more thinking of those routed directly to the native (non-compat) syscalls. We would need to make sure the return value (X0 being the only register not restored on return from exception) has the top 32-bit part zeroed. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Catalin, even though this may now be moot, as we’ll out a 32bit time_t on ILP32 (making it very similar to n32 on MIPS), here’s the the info on what would be affected by changing timespec. Below is a (hopefully) full list of system calls, helper functions and exposed data structures (with some comments on what will need to be done to resolve this change) that would be affected by introducing an other timespec (let’s call it ilp32_timespec for the ease of discussion) consisting of a 64bit time_t and a 32bit integer. > On 14 Apr 2015, at 18:55, Catalin Marinas wrote: > > As I mentioned above, timespec and possibly other structures no longer > like any of the existing ABIs. Do we know how many syscalls are > affected? Here’s everything that affected (details on how to resolve are below) in no particular order: > syscall: utimensat > syscall: io_getevents > syscall: select > internal: poll_select_copy_remaining (via select) [+on stack: struct > compat_timespec rts;] > syscall: pselect6 > internal: do_compat_pselect (via pselect6) [+on stack: struct compat_timespec > ts;] > syscall: ppoll [+on stack: struct compat_timespec ts;] > syscall: nanosleep > internal: compat_nanosleep_restart (via nanosleep) > syscall: clock_gettime > syscall: clock_settime > syscall: clock_getres > syscall: clock_nanosleep > syscall: rt_sigtimedwait > syscall: sched_rr_get_interval > internal: compat_get_timespec > internal: compat_put_timespec > syscall: futex > syscall: recvmmsg > file_operations: compat_sock_ioctl > internal: do_siocgstampns (via compat_sock_ioctl_trans via compat_sock_ioctl) > syscall: semtimedop > syscall: mq_timedsend > syscall: mq_timedreceive > internal: compat_convert_timespec > syscall: timer_settime > syscall: timer_gettime > syscall: timerfd_settime > syscall: timerfd_gettime > struct: itimerspec > internal: get_compat_itimerspec > internal: put_compat_itimerspec > struct: snd_pcm_status32 > internal: snd_pcm_ioctl_sync_ptr_compat > struct: snd_pcm_mmap_status32 > internal: snd_pcm_status_user_compat > struct: v4l2_event32 > internal: put_v4l2_event32 (via do_video_ioctl) > struct: restart_block [simple change: additional field; for nanosleep] > internal: put_cmsg_compat [on stack: struct compat_timespec cts[3];] > struct: snd_rawmidi_status32 > internal: snd_rawmidi_ioctl_status_compat (handles snd_rawmidi_status32) > struct: snd_timer_status32 > internal: snd_timer_user_status_compat > struct: struct snd_pcm_mmap_status32 > internal: snd_pcm_ioctl_sync_ptr_compat (handles snd_pcm_mmap_status32) > struct: snd_pcm_status32 > internal: snd_pcm_status_user_compat (handles snd_pcm_status32) For dealing with them, we can roughly use the following strategy (I may have lost 1. The timespec/compat_timespec/ilp32_timespec is ever only referenced through its memory address and used for userspace/kernel-transfers. For these cases we mere need to extend the compat_get_timespec and compat_put_timespec functions to recognize the ILP32-case… same for compat_convert_timespec For the affected syscalls, the ILP32 implementation should route through the compat-layer. This can be done in the following cases (I’m leaving the compat off for readability): utimensat io_getevents nanosleep clock_gettime clock_settime clock_getres clock_nanosleep rt_sigtimedwait sched_rr_get_interval recvmmsg futex semtimedop mq_timedsend mq_timedreceive One helper called through an ioctl will also need to pick this us: do_siocgstampns (through compat_sock_ioctl) A special case is the nanosleep syscall and its restart-helper: even though less apparent, this would be covered by the changes to compat_get_timespec and compat_put_timespec also (as there’s only a pointer to a compat_timespec involved). 2. An similar change will be required for anything that uses itimerspec (as that structure contains two timespec elements): timer_settime timer_gettime timerfd_settime timerfd_gettime 3. A compat_timespec is currently created on the stack, even though it’s used only for a get_user/put_user in a few cases; this can be resolved by changing to use compat_get_timespec/compat_put_timespec. Once this has been done, then the changes from step 1 should also extend to these case. Instances include: poll_select_copy_remaining (helper function called from ‘select’) do_compat_pselect (helper function called from ‘pselect6’) ppoll The syscalls associated with these helper-functions need to be passed through the compat-layer
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: > On 15 Apr 2015, at 00:28, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: > >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: > >>> For completeness, there is yet another option, which would be to use the > >>> exact system call table from arm64 and do all the emulation in user space > >>> rather than the kernel. This would however be the least compatible with > >>> existing source code, so you probably don't want to do that. > >> > >> It would be great if this worked but I think we looked at it before and > >> it seems nice until you hit the futex stuff and robust lists (I don't > >> fully remember the details). Some of the structures (siginfo) would no > >> longer be POSIX compliant and some of them aren't only accessed via libc > >> to be able to create shadow copies. > > > > Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to > > enable a very special class of applications, it's not like anyone would > > want to run a full system for this and need POSIX compliance. > > I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 > ecosystem as a “data-model” for AArch64. Having a corresponding Linux > syscall ABI is necessitated because not all data structures shared across > the syscall-boundary are describted/defined in data-model agnostic types. > ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus > neither a hack nor likely/expected to go away anytime soon. That's the kind of feedback I've been trying to get from the software ecosystem - whether AArch64-ILP32 is a temporary hack for legacy 32-bit applications or a solid long term solution for those not needing 64-bit. The benchmarks I've seen so far didn't show any significant improvement of AArch64-ILP32 over LP64. The comparison with AArch32 may not be entirely fair at the moment due to the maturity of AArch64-ILP32 toolchains but I don't think we'll see a big jump. The messages I get are mixed, even from companies initially stating the need for ILP32. So I can't make an informed decision but I think we should go for the safer option: a first class citizen, long term ABI. It costs more in (kernel) maintenance initially but if it happens to catch on, it will cost us later. The alternative is not to bother with AArch64-ILP32 at all, especially if it's going to be used only as a marketing exercise for CPUs not supporting AArch32. (if anyone has more feedback on commercial needs for ILP32, please let us know, even if it is in private) > We’ve run full systems (built from buildroot) consisting of ILP32 binaries > only (ok… admittedly gdb was an exception, as we haven’t fixed the fact > that someone has assumed sizeof(long) == 8 in some data-structure of > the AArch64 backend there) in our verification runs. In fact, it will be very > special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). > > We could definitely be pragmatic and do whatever helps get the job > > done. That said, it diverges further from what legacy 32-bit applications > > expect to see, so this approach will likely make an application port harder, > > not easier. > > The key question at this point seems to be whether we want to support > “legacy 32-bit applications” (i.e. ones that make assumption that are > not covered by the underlying type definitions or specifications) or whether > we aim for “well-formed 32-bit applications”. > > To stay with the 'struct timespec’-example, the difference between the > former and the latter would (among others) be that the former might > assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to > except that sizeof(long) == sizeof(ts.tv_nsec). > > I don’t believe in keeping compatibility for the former type of applications. That was one of the initial reasons I heard for AArch64-ILP32. So more mixed messages. > Consequently, I don’t necessarily see the value in defining ILP32 for > AArch64 with a 32bit time_t (even though it would be simpler at this > moment), as I don’t see the benefit of adding a new ABI that propagates > a well known problem (even if one could argue that there’s plenty of time > to fix this by 2038). We could look at this in a different way: time_t should be the same size as any *new* 32-bit architecture supported by Linux. So if the kernel community decides that from now on time_t is 64-bit across new 32 and 64-bit architecture ports (note new, not existing), we do the same with ILP32. Otherwise, we stick to 32-bit time_t and wait to see how the 2038 problem is solved, possibly with extensions to POSIX and additional syscalls. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 15 Apr 2015, at 00:28, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: >>> For completeness, there is yet another option, which would be to use the >>> exact system call table from arm64 and do all the emulation in user space >>> rather than the kernel. This would however be the least compatible with >>> existing source code, so you probably don't want to do that. >> >> It would be great if this worked but I think we looked at it before and >> it seems nice until you hit the futex stuff and robust lists (I don't >> fully remember the details). Some of the structures (siginfo) would no >> longer be POSIX compliant and some of them aren't only accessed via libc >> to be able to create shadow copies. > > Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to > enable a very special class of applications, it's not like anyone would > want to run a full system for this and need POSIX compliance. I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 ecosystem as a “data-model” for AArch64. Having a corresponding Linux syscall ABI is necessitated because not all data structures shared across the syscall-boundary are describted/defined in data-model agnostic types. ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus neither a hack nor likely/expected to go away anytime soon. We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If anything, then backward-compatibility for ARMv7 binaries should be considered a hack (although one that is performed in hardware). > We could definitely be pragmatic and do whatever helps get the job > done. That said, it diverges further from what legacy 32-bit applications > expect to see, so this approach will likely make an application port harder, > not easier. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. Consequently, I don’t necessarily see the value in defining ILP32 for AArch64 with a 32bit time_t (even though it would be simpler at this moment), as I don’t see the benefit of adding a new ABI that propagates a well known problem (even if one could argue that there’s plenty of time to fix this by 2038). Phil.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 16:54:22 Dr. Philipp Tomsich wrote: On 14 Apr 2015, at 16:07, Arnd Bergmann a...@arndb.de wrote: I don't understand what you mean here, please elaborate. Why would an ABI that works on aarch32 be wrong on aarch64-ilp32 user space when you are using the same header files? AArch32 and AArch64/ILP32 are entirely different instruction set architectures. They have differently sized register files (AArch64 has about twice as many registers and each one is 64bits in size) and different register usage conventions. This affects other “implementation details” such as the ucontext, too. For the sake of simplicity, I’ll refer to it just as “register file” below. This means that we would end up with very distinct code paths for the “dependent” in tools (such as strace), if option (d) was used: LP64: AArch64 context + 64bit syscall interface ILP32: AArch64 context + 32bit syscall interface AArch32:AArch32 context + 32bit syscall interface If we could agree on option (b), things would be much simpler: LP64: AArch64 context + 64bit syscall interface ILP32: AArch64 context + 64bit syscall interface + ILP32 compat-syscalls AArch32:AArch32 context + 32bit syscall interface I.e. for all tools involved (whether it’s strace, gdb, etc.), LP64 and ILP32 can and should look very similar. After all, they differ in their sizeof(ptr_t) and sizeof(long), only. AArch32, on the other hand, is very dissimilar to AArch64… it’s a different architecture. But this is talking from a tools-perspective... Ok, I see. From the kernel perspective, this is very different: The compat syscall handling in the kernel is fixed to the aarch32 behavior, and in particular ioctl (but also a few others) in the current patch set need to share that syscall between both IPL32 implementations (you can't use the LP64 version). This means any data structure that can get passed into ioctl needs to share the exact same layout between all ILP32 ABIs, or it would be a bug in the kernel until someone fixes the driver to handle all three data structure formats. I thought until today that this would be limited to ioctl arguments derived from the __kernel_ulong_t derived types I mentioned (__kernel_size_t, __kernel_time_t, __kernel_ptrdiff_t, __kernel_off_t, __kernel_clock_t, __kernel_ino_t, ...), but the problem is actually bigger than that and also concerns types that are different between the traditional arm32 types and the widened asm-generic types (__kernel_uid_t, __kernel_gid_t, __kernel_mode_t, __kernel_off_t, __kernel_ipc_pid_t). If we use the generic definitions for all those types, we cannot use the existing compat_sys_ioctl() system call. If we use the aarch32 definitions, we also have to use the other compat_sys_* calls that aarch32 uses in place of the native ones (though a lot of syscalls are not needed any more in general). Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 17:55:00 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote: So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C language. Any program that assumes that tv_nsec is sizeof(long) would be correct and it would be unexpected and surprising behaviour [even though it would be consider a good programming style] if one would need to explicitly ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem like a good justification to do the same. From a standards perspective, that's clear, and I'm fine with not making the same choice as x32. I think on x32 it was a side-effect of glibc defining tv_nsec as __syscall_slong_t and the kernel defining __kernel_long_t to 64-bit. I'm pretty sure that this part of the x32 ABI was a deliberate choice in full knowledge of the tradeoffs. For time_t, I don’t see the need to have a 32bit type yet. As long as the the type is properly exposed through header files (and user programs can thus recreate the kernel’s data model), we should be safe. The problem with a 64-bit time_t is that the timespec structure looks like neither compat32 nor native 64-bit. If we make the AArch32 and native ILP32 exclusive and build time, it makes it easier, otherwise we need to support a third ABI in the kernel. Exactly, which is why the layout was chosen to be the same as x86-64 for x32. Can we thus agree on the following for the next revision of the patch-set: (1) We retain a 64bit time_t, but implement different sizes (between ILP32 and LP64) for ‘tv_nsec' in 'struct timespec’? (2) We use the 64bit system calls whereever possible (i.e. no register splitting). As I mentioned above, timespec and possibly other structures no longer like any of the existing ABIs. Do we know how many syscalls are affected? The alternative is 32-bit time_t which makes it easier to use the compat syscall implementations (not numbers). It also depends on how we plan to fix the 2038 problem. For new 32-bit only architectures, are we going to require them to use a 64-bit time_t or we get alternative time64_t and timespec64 specs? No, we had originally planned that a few years ago, but after deciding that we are fixing this problem for all 32-bit machines, and also seeing the magnitude of changes involved in that, I think we have a general consensus that we do not want to add special cases for architectures that use 64-bit time_t before everyone else does. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com wrote:
I mainly want to avoid accidentally creating new ABIs for syscalls and
ioctls:
we have many drivers that today use ioctls with data structures derived
from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs)
*/
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
That's indeed a problem as ILP32 doesn't look like any of the other
options (the siginfo structure is another case that doesn't fit in any
of the ABI as long as time_t is 64-bit).
I believe we’ve already arrived at the conclusion that timespec needs to be
changed from what Andrew and I had submitted.
Let’s go back to the underlying definition of timespec:
The range and precision of times representable in clock_t and time_t
are
implementation-defined. The timespec structure shall contain at least
the
following members, in any order.
time_t tv_sec; // whole seconds -- = 0
long tv_nsec; // nanoseconds -- [0, 9]”
So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
language. Any program that assumes that tv_nsec is sizeof(long) would be
correct and it would be unexpected and surprising behaviour [even though it
would be consider a good programming style] if one would need to explicitly
ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
like a good justification to do the same.
I don't think assuming that people who don't write 64-bit safe code
write code that follows C11 is realistic ;-)
A lot more code is broken by having a 64-bit time_t than would be
broken by making tv_nsec 64-bit.
For time_t, I don’t see the need to have a 32bit type yet.
As long as the the type is properly exposed through header files (and user
programs can thus recreate the kernel’s data model), we should be safe.
Cases like the above data structure from an ioctl are clearly non-portable
and would break today on any architecture that supports ABIs with different
data models (say ILP32 and LP64)… so I would consider any attempt to
support this as trying to remain “bug-compatible”.
There are plenty of good examples in the uapi that will be nicely portable
between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this,
as the userspace library libaio uses a broken redefinition instead of the
kernel header file) as an example:
/*
...
structures that done in modern times by competent developers should all
be the same across the three ABIs, no need to worry about that.
The only worrying part is drivers that are written in an incompatible
form for whatever reason. These have become rarer in the recent years,
but we still see new ones getting merged, e.g. the Android binder.
The key to any design decision should be that we
(a) don’t break C11, POSIX or the Single UNIX Specification
(b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
(which defines 64bit values transferable in registers to callees)
These are nice goals, but I don't think they primary objectives.
Getting things to work is much more important, and the timespec
definition among other things may end up not being standards compliant
in order to get there.
Can we thus agree on the following for the next revision of the patch-set:
(1) We retain a 64bit time_t, but implement different sizes (between ILP32
and
LP64) for ‘tv_nsec' in 'struct timespec’?
I have a plan for addressing that, but it will likely take another year
before we can get consensus on the timespec layout for 64-bit time_t.
At the moment, it looks like the 64/64 layout has more support than the
64/pad/32 layout you are describing. Let's not rush this for aarch64
when there is a chance that we end up with a different layout on
native 32-bit machines.
(2) We use the 64bit system calls
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: On 15 Apr 2015, at 00:28, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 ecosystem as a “data-model” for AArch64. Having a corresponding Linux syscall ABI is necessitated because not all data structures shared across the syscall-boundary are describted/defined in data-model agnostic types. ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus neither a hack nor likely/expected to go away anytime soon. That's the kind of feedback I've been trying to get from the software ecosystem - whether AArch64-ILP32 is a temporary hack for legacy 32-bit applications or a solid long term solution for those not needing 64-bit. The benchmarks I've seen so far didn't show any significant improvement of AArch64-ILP32 over LP64. The comparison with AArch32 may not be entirely fair at the moment due to the maturity of AArch64-ILP32 toolchains but I don't think we'll see a big jump. The messages I get are mixed, even from companies initially stating the need for ILP32. So I can't make an informed decision but I think we should go for the safer option: a first class citizen, long term ABI. It costs more in (kernel) maintenance initially but if it happens to catch on, it will cost us later. The alternative is not to bother with AArch64-ILP32 at all, especially if it's going to be used only as a marketing exercise for CPUs not supporting AArch32. Agreed on all this. (if anyone has more feedback on commercial needs for ILP32, please let us know, even if it is in private) We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. That was one of the initial reasons I heard for AArch64-ILP32. So more mixed messages. Of course you hear different stories from different people, and some of them might just be asking for things they don't fully understand. As far as I'm concerned, supporting broken legacy applications in the *only* reason we should be doing this for. If people are asking for it because x86 does it, for performance or because it lines up nicely with what the toolchain can do, I'm more than happy to ignore them. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. I agree with this not being a prerequisite for merging ILP32 but at least a long term plan to do something beyond openembedded, once we agreed on the ABI and _upstreamed_ the kernel and glibc code. Those legacy applications will probably need more than glibc to run and it's likely that people will want to run them in a full AArch64 (LP64) environment. A simpler approach (to me, I'm not a distro person) would be to just provide additional ILP32 libs in a multi-lib arm64 distro like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. That was one of the initial reasons I heard for AArch64-ILP32. So more mixed messages. Of course you hear different stories from different people, and some of them might just be asking for things they don't fully understand. As far as I'm concerned, supporting broken legacy applications in the *only* reason we should be doing this for. If people are asking for it because x86 does it, for performance or because it lines up nicely with what the toolchain can do, I'm more than happy to ignore them. I'm not even debating this for the lack of market feedback. So I tend to agree with you. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote: On 15 Apr 2015, at 13:22, Catalin Marinas catalin.mari...@arm.com wrote: I think you are right. I was more thinking of those routed directly to the native (non-compat) syscalls. We would need to make sure the return value (X0 being the only register not restored on return from exception) has the top 32-bit part zeroed. As the kernel is LP64 and will thus attempt to return a 64bit return value, the high bits should be properly sign-extended in all cases. The problem (posed by procedure call standard) of information leakage could manifest itself only, if the kernel tried to return something smaller than 64 bits… in that case, we can the problem would already exhibit for the LP64 ABI. For the ILP32 implementation, I’ll thus assume that all LP64 ABI calls reused are clean in this regard. Yes. All the compat_sys_* are defined to return a long, so even if ILP32 user space treats it as 32-bit, there is no information leak because of the kernel's sign-extension. So just a false alarm, we can consider this part sorted. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On 15 Apr 2015, at 17:38, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. I agree with this not being a prerequisite for merging ILP32 but at least a long term plan to do something beyond openembedded, once we agreed on the ABI and _upstreamed_ the kernel and glibc code. Those legacy applications will probably need more than glibc to run and it's likely that people will want to run them in a full AArch64 (LP64) environment. A simpler approach (to me, I'm not a distro person) would be to just provide additional ILP32 libs in a multi-lib arm64 distro like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, termcap, zlib and a few others in a multiarch setup… this was used in the field by customers and worked rather well. One of the engineers in my team is currently working on carrying this forward so we can use this for any Debian-based AArch64 distribution in the future. Best, Phil. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote: On 15 Apr 2015, at 17:38, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. I agree with this not being a prerequisite for merging ILP32 but at least a long term plan to do something beyond openembedded, once we agreed on the ABI and _upstreamed_ the kernel and glibc code. Those legacy applications will probably need more than glibc to run and it's likely that people will want to run them in a full AArch64 (LP64) environment. A simpler approach (to me, I'm not a distro person) would be to just provide additional ILP32 libs in a multi-lib arm64 distro like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, termcap, zlib and a few others in a multiarch setup… this was used in the field by customers and worked rather well. One of the engineers in my team is currently working on carrying this forward so we can use this for any Debian-based AArch64 distribution in the future. That sounds great. What I'm looking for is to be able to build something like LTP to be able to reproduce the testing before merging the code. So the PPA approach looks good. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On 15.04.15 19:22, Catalin Marinas wrote: On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote: On 15 Apr 2015, at 17:38, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). I actually don't think this should be a prerequisite. We have too many dependencies here, and as long as we are debating the exact ABI, any work that gets put into a full distro support (other than openembedded etc) would likely be wasted. I agree with this not being a prerequisite for merging ILP32 but at least a long term plan to do something beyond openembedded, once we agreed on the ABI and _upstreamed_ the kernel and glibc code. Those legacy applications will probably need more than glibc to run and it's likely that people will want to run them in a full AArch64 (LP64) environment. A simpler approach (to me, I'm not a distro person) would be to just provide additional ILP32 libs in a multi-lib arm64 distro like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, termcap, zlib and a few others in a multiarch setup… this was used in the field by customers and worked rather well. One of the engineers in my team is currently working on carrying this forward so we can use this for any Debian-based AArch64 distribution in the future. That sounds great. What I'm looking for is to be able to build something like LTP to be able to reproduce the testing before merging the code. So the PPA approach looks good. We've just started to bootstrap openSUSE for ILP32 with the non-final abi. However, keep in mind that at least for us bootstrapping is a manual process. So changing syscall numbers means we'll need to go through the manual process again. So if you need any help on getting you an environment that allows you to build LTP with whatever syscall abi people come up with, feel free to poke Andreas or me. Alex PS: This mail does not include any commitment to maintain an ILP32 openSUSE distribution ;) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Catalin, even though this may now be moot, as we’ll out a 32bit time_t on ILP32 (making it very similar to n32 on MIPS), here’s the the info on what would be affected by changing timespec. Below is a (hopefully) full list of system calls, helper functions and exposed data structures (with some comments on what will need to be done to resolve this change) that would be affected by introducing an other timespec (let’s call it ilp32_timespec for the ease of discussion) consisting of a 64bit time_t and a 32bit integer. On 14 Apr 2015, at 18:55, Catalin Marinas catalin.mari...@arm.com wrote: As I mentioned above, timespec and possibly other structures no longer like any of the existing ABIs. Do we know how many syscalls are affected? Here’s everything that affected (details on how to resolve are below) in no particular order: syscall: utimensat syscall: io_getevents syscall: select internal: poll_select_copy_remaining (via select) [+on stack: struct compat_timespec rts;] syscall: pselect6 internal: do_compat_pselect (via pselect6) [+on stack: struct compat_timespec ts;] syscall: ppoll [+on stack: struct compat_timespec ts;] syscall: nanosleep internal: compat_nanosleep_restart (via nanosleep) syscall: clock_gettime syscall: clock_settime syscall: clock_getres syscall: clock_nanosleep syscall: rt_sigtimedwait syscall: sched_rr_get_interval internal: compat_get_timespec internal: compat_put_timespec syscall: futex syscall: recvmmsg file_operations: compat_sock_ioctl internal: do_siocgstampns (via compat_sock_ioctl_trans via compat_sock_ioctl) syscall: semtimedop syscall: mq_timedsend syscall: mq_timedreceive internal: compat_convert_timespec syscall: timer_settime syscall: timer_gettime syscall: timerfd_settime syscall: timerfd_gettime struct: itimerspec internal: get_compat_itimerspec internal: put_compat_itimerspec struct: snd_pcm_status32 internal: snd_pcm_ioctl_sync_ptr_compat struct: snd_pcm_mmap_status32 internal: snd_pcm_status_user_compat struct: v4l2_event32 internal: put_v4l2_event32 (via do_video_ioctl) struct: restart_block [simple change: additional field; for nanosleep] internal: put_cmsg_compat [on stack: struct compat_timespec cts[3];] struct: snd_rawmidi_status32 internal: snd_rawmidi_ioctl_status_compat (handles snd_rawmidi_status32) struct: snd_timer_status32 internal: snd_timer_user_status_compat struct: struct snd_pcm_mmap_status32 internal: snd_pcm_ioctl_sync_ptr_compat (handles snd_pcm_mmap_status32) struct: snd_pcm_status32 internal: snd_pcm_status_user_compat (handles snd_pcm_status32) For dealing with them, we can roughly use the following strategy (I may have lost 1. The timespec/compat_timespec/ilp32_timespec is ever only referenced through its memory address and used for userspace/kernel-transfers. For these cases we mere need to extend the compat_get_timespec and compat_put_timespec functions to recognize the ILP32-case… same for compat_convert_timespec For the affected syscalls, the ILP32 implementation should route through the compat-layer. This can be done in the following cases (I’m leaving the compat off for readability): utimensat io_getevents nanosleep clock_gettime clock_settime clock_getres clock_nanosleep rt_sigtimedwait sched_rr_get_interval recvmmsg futex semtimedop mq_timedsend mq_timedreceive One helper called through an ioctl will also need to pick this us: do_siocgstampns (through compat_sock_ioctl) A special case is the nanosleep syscall and its restart-helper: even though less apparent, this would be covered by the changes to compat_get_timespec and compat_put_timespec also (as there’s only a pointer to a compat_timespec involved). 2. An similar change will be required for anything that uses itimerspec (as that structure contains two timespec elements): timer_settime timer_gettime timerfd_settime timerfd_gettime 3. A compat_timespec is currently created on the stack, even though it’s used only for a get_user/put_user in a few cases; this can be resolved by changing to use compat_get_timespec/compat_put_timespec. Once this has been done, then the changes from step 1 should also extend to these case. Instances include: poll_select_copy_remaining (helper function called from ‘select’) do_compat_pselect (helper function called from ‘pselect6’) ppoll The syscalls associated with these helper-functions need to be passed through the compat-layer for ILP32 also (as functions in
Re: [PATCH v4 00/24] ILP32 for ARM64
On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: On 15 Apr 2015, at 00:28, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 ecosystem as a “data-model” for AArch64. Having a corresponding Linux syscall ABI is necessitated because not all data structures shared across the syscall-boundary are describted/defined in data-model agnostic types. ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus neither a hack nor likely/expected to go away anytime soon. That's the kind of feedback I've been trying to get from the software ecosystem - whether AArch64-ILP32 is a temporary hack for legacy 32-bit applications or a solid long term solution for those not needing 64-bit. The benchmarks I've seen so far didn't show any significant improvement of AArch64-ILP32 over LP64. The comparison with AArch32 may not be entirely fair at the moment due to the maturity of AArch64-ILP32 toolchains but I don't think we'll see a big jump. The messages I get are mixed, even from companies initially stating the need for ILP32. So I can't make an informed decision but I think we should go for the safer option: a first class citizen, long term ABI. It costs more in (kernel) maintenance initially but if it happens to catch on, it will cost us later. The alternative is not to bother with AArch64-ILP32 at all, especially if it's going to be used only as a marketing exercise for CPUs not supporting AArch32. (if anyone has more feedback on commercial needs for ILP32, please let us know, even if it is in private) We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If we are to merge AArch64-ILP32, I'd like to see a full software stack, maybe a distro like Debian. Otherwise the kernel code will bit-rot (just like it regularly happens with big endian). We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. That was one of the initial reasons I heard for AArch64-ILP32. So more mixed messages. Consequently, I don’t necessarily see the value in defining ILP32 for AArch64 with a 32bit time_t (even though it would be simpler at this moment), as I don’t see the benefit of adding a new ABI that propagates a well known problem (even if one could argue that there’s plenty of time to fix this by 2038). We could look at this in a different way: time_t should be the same size as any *new* 32-bit architecture supported by Linux. So if the kernel community decides that from now on time_t is 64-bit across new 32 and 64-bit architecture ports (note new, not existing), we do the same with ILP32. Otherwise, we stick to 32-bit time_t and wait to see how the 2038 problem is solved, possibly with extensions to POSIX and additional syscalls. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH v4 00/24] ILP32 for ARM64
On 15 Apr 2015, at 00:28, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 ecosystem as a “data-model” for AArch64. Having a corresponding Linux syscall ABI is necessitated because not all data structures shared across the syscall-boundary are describted/defined in data-model agnostic types. ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus neither a hack nor likely/expected to go away anytime soon. We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If anything, then backward-compatibility for ARMv7 binaries should be considered a hack (although one that is performed in hardware). We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. Consequently, I don’t necessarily see the value in defining ILP32 for AArch64 with a 32bit time_t (even though it would be simpler at this moment), as I don’t see the benefit of adding a new ABI that propagates a well known problem (even if one could argue that there’s plenty of time to fix this by 2038). Phil.-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 05:44:07PM +0200, Arnd Bergmann wrote: On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote: 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 IMO, (d) only makes sense if we treat ILP32 as a temporary solution (a.k.a. hack) hoping that such applications will be eventually built for LP64. If we treat native ILP32 as a real long term alternative to LP64, I would rather use the asm-generic/unistd.h for syscalls. For example, use 'openat' instead of 'open' on the native ILP32 (based on the assumption that ILP32 is a long term alternative). Unless we are aware of performance impact with (a), that's my preferred option with some form of (b) next. Ok, let's call that option e) Use the existing aarch32 data structures with the asm-generic/unistd.h system call numbers. This would solve the main problem of the data structures just like option d), and the main user-visible change would be that the syscall numbers are shifted compared to aarch32, which is a very minor aspect. We could also deal with the ucontext better this way than what I suggested. I think that's the easiest from a kernel perspective. But see the other sub-thread on the long term view of ILP32 (beyond 2038). The above is mainly about syscall numbers and tables but the ABI goes beyond this. And the key point is whether we go for an AArch32-like ABI (32-bit time_t) or we try to define one close to LP64. If we go for an AArch32-like ABI, we'll have to use the compat layer for some of syscalls and assess how many of the asm/compat.h structures are different from the generic ones (I wouldn't expect many). It would be wildly different from the generic data structures, since we can only use the compat code if the implementation is the same as on aarch32. Essentially we have to define the headers so that all native data structures match what is in arch/arm64/include/asm/compat.h, which in turn is largely the same as arch/arm/include/uapi/asm/*.h. What I meant by generic structures is those include/uapi/asm-generic/*.h structures but compiled in an ILP32 context (exported headers not as they are compiled in the LP64 kernel). Many of the asm/compat.h had to be defined so that we can build them in the kernel context but many of them are the same as the asm-generic ones (when compiled as ILP32). BTW, we have to sort out the exported headers as well since we can't rely on AArch32 for this. In the kernel, we'll have to re-use asm/compat.h or some other asm/ilp32.h. Finally, there is a certain set of security issues from each new syscall we introduce. With the aarch32 syscall table, we have a higher degree of reuse of existing code, so we won't introduce security bugs that are only in one of the two ilp32 ABIs (aarch32 and aarch64). Note that the current aarch32 compat ABI assumes that the top 32-bit of every register is either zeroed or preserved by the architecture on exception entry. We know that an AArch32 application cannot access the top 32-bit of an AArch64 register. With native ILP32 however this is no longer the case (it is running in AArch64 mode). I can't immediately think of a problem (information leak) but it needs to be reviewed. Hmm, interesting point. I'd have to think about this a bit more, but I believe it is already solved: - For input arguments, we have the COMPAT_SYSCALL_DEFINE wrappers that are meant to deal with this problem. - For output arguments, the kernel controls the register contents, and I don't see a way that the function return value could leak data in the upper bits. All syscall return 'long', so it should be well-defined. I think you are right. I was more thinking of those routed directly to the native (non-compat) syscalls. We would need to make sure the return value (X0 being the only register not restored on return from exception) has the top 32-bit part zeroed. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: > On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: > > For completeness, there is yet another option, which would be to use the > > exact system call table from arm64 and do all the emulation in user space > > rather than the kernel. This would however be the least compatible with > > existing source code, so you probably don't want to do that. > > It would be great if this worked but I think we looked at it before and > it seems nice until you hit the futex stuff and robust lists (I don't > fully remember the details). Some of the structures (siginfo) would no > longer be POSIX compliant and some of them aren't only accessed via libc > to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
> > On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and
> >> ioctls:
> >> we have many drivers that today use ioctls with data structures derived
> >> from
> >> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
> >> their own data structures. These are almost all broken today, because the
> >> data structures are a mix of the aarch32 and aarch64 variants, while the
> >> ioctl() system call in ilp32 always uses the aarch32 format by default.
> >>
> >> An example here would be
> >>
> >> struct cyclades_idle_stats {
> >>__kernel_time_t in_use; /* Time device has been in use (secs) */
> >>__kernel_time_t recv_idle; /* Time since last char received (secs) */
> >>__kernel_time_t xmit_idle; /* Time since last char transmitted (secs)
> >> */
> >>unsigned long recv_bytes; /* Bytes received */
> >>unsigned long xmit_bytes; /* Bytes transmitted */
> >>unsigned long overruns;/* Input overruns */
> >>unsigned long frame_errs; /* Input framing errors */
> >>unsigned long parity_errs; /* Input parity errors */
> >> };
> >>
> >> for a random ancient driver. Introducing a third set of data structures
> >> and syscalls for aarch64-ilp32 means that any driver doing something like
> >> this needs to be modified to support existing user space source code.
> >
> > That's indeed a problem as ILP32 doesn't look like any of the other
> > options (the siginfo structure is another case that doesn't fit in any
> > of the ABI as long as time_t is 64-bit).
>
> I believe we’ve already arrived at the conclusion that timespec needs to be
> changed from what Andrew and I had submitted.
>
> Let’s go back to the underlying definition of timespec:
> "The range and precision of times representable in clock_t and time_t
> are
> implementation-defined. The timespec structure shall contain at least
> the
>following members, in any order.
>
>time_t tv_sec; // whole seconds -- >= 0
>long tv_nsec; // nanoseconds -- [0, 9]”
>
> So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
> language. Any program that assumes that tv_nsec is sizeof(long) would be
> correct and it would be unexpected and surprising behaviour [even though it
> would be consider a good programming style] if one would need to explicitly
> ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
> like a good justification to do the same.
>From a standards perspective, that's clear, and I'm fine with not making
the same choice as x32. I think on x32 it was a side-effect of glibc
defining tv_nsec as __syscall_slong_t and the kernel defining
__kernel_long_t to 64-bit.
> For time_t, I don’t see the need to have a 32bit type yet.
> As long as the the type is properly exposed through header files (and user
> programs can thus recreate the kernel’s data model), we should be safe.
The problem with a 64-bit time_t is that the timespec structure looks
like neither compat32 nor native 64-bit. If we make the AArch32 and
native ILP32 exclusive and build time, it makes it easier, otherwise we
need to support a third ABI in the kernel.
> The key to any design decision should be that we
> (a) don’t break C11, POSIX or the Single UNIX Specification
> (b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
> (which defines 64bit values transferable in registers to callees)
I think these are fine.
> Can we thus agree on the following for the next revision of the patch-set:
> (1) We retain a 64bit time_t, but implement different sizes (between ILP32
> and
> LP64) for ‘tv_nsec' in 'struct timespec’?
> (2) We use the 64bit system calls whereever possible (i.e. no register
> splitting).
As I mentioned above, timespec and possibly other structures no longer
like any of the existing ABIs. Do we know how many syscalls are
affected?
The alternative is 32-bit time_t which makes it easier to use the compat
syscall implementations (not numbers). It also depends on how we plan to
fix the 2038 problem. For new 32-bit only architectures, are we going to
require them to use a 64-bit time_t or we get alternative time64_t and
timespec64 specs?
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote:
> On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> > > 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:
>
> It doesn't look like they are exclusive options. For example you can use
> (a) together with (c) or (d). Some more comments below:
I meant them to be exclusive, but you are right that the list
was not complete, and it's possible to interpret it different
from what I had in mind.
> > a) separate syscall table for arm64: as you say, this is the current
> > approach,
> >and I'd like to avoid that too
>
> What is the problem with this option? Is it cache locality affected by
> having another table? A syscall table currently stands at around 2KB. We
> could halve it by storing relative offsets but I don't think we would
> notice much performance improvement.
No, I'm not worried about performance here, the main differences to b) and c)
here is that you have to maintain this list, and potentially duplicate it
for new 64-bit architectures coming in (x86, mips etc already have separate
copies, so that ship has sailed). I'd rather see that table being maintained
in asm-generic as architecture independent code than in arch/arm64.
The much bigger problem of data structures that are incompatible with both
existing ABIs is shared with approach b and c.
> > 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
>
> Does this mean that an ILP32 task can still call LP64-only syscalls? How
> many new syscalls are we looking at? Would these ILP32 numbers be
> interspersed with the LP64 ones or some high values (say bit 12 set)?
> The former isn't workable since may leave gaps on LP64 architectures.
> The latter could work better if the ILP32 specific options are not
> sparse.
This would be the same list that patch 19/24 of this series adds, 32
system calls in total, possibly a few more getting added over the
years.
> > 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
>
> I don't fully understand this. It looks to me like we need to generate
> at least the LP64 and native ILP32 unistd.h anyway if we go for option a
> or possibly b.
With option b), we'd generate one table from asm-generic/unistd.h and
another one from asm/unistd32.h, as we do today. The first would be
shared between both aarch64 ABIs (and extended with 32 new calls) while
the second continues unmodified.
With option c), we'd use the asm-generic/unistd.h source to generate
two independent tables, similar to what we do in
arch/tile/kernel/{sys,compat}.c, and the first table would be the same
as it is 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
>
> IMO, (d) only makes sense if we treat ILP32 as a temporary solution
> (a.k.a. hack) hoping that such applications will be eventually built for
> LP64. If we treat native ILP32 as a real long term alternative to LP64,
> I would rather use the asm-generic/unistd.h for syscalls. For example,
> use 'openat' instead of 'open' on the native ILP32 (based on the
> assumption that ILP32 is a long term alternative).
>
> Unless we are aware of performance impact with (a), that's my preferred
> option with some form of (b) next.
Ok, let's call that option
e) Use the existing aarch32 data structures with the asm-generic/unistd.h
system call numbers.
This would solve the main problem of the data structures just like option
d), and the main user-visible change would be that the syscall numbers
are shifted compared to aarch32, which is a very minor aspect. We could
also deal with the ucontext better this way than what I suggested.
> The above is mainly about syscall numbers and tables but the ABI goes
> beyond this.
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
>
>> I mainly want to avoid accidentally creating new ABIs for syscalls and
>> ioctls:
>> we have many drivers that today use ioctls with data structures derived from
>> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
>> their own data structures. These are almost all broken today, because the
>> data structures are a mix of the aarch32 and aarch64 variants, while the
>> ioctl() system call in ilp32 always uses the aarch32 format by default.
>>
>> An example here would be
>>
>> struct cyclades_idle_stats {
>>__kernel_time_t in_use; /* Time device has been in use (secs) */
>>__kernel_time_t recv_idle; /* Time since last char received (secs) */
>>__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
>>unsigned long recv_bytes; /* Bytes received */
>>unsigned long xmit_bytes; /* Bytes transmitted */
>>unsigned long overruns;/* Input overruns */
>>unsigned long frame_errs; /* Input framing errors */
>>unsigned long parity_errs; /* Input parity errors */
>> };
>>
>> for a random ancient driver. Introducing a third set of data structures
>> and syscalls for aarch64-ilp32 means that any driver doing something like
>> this needs to be modified to support existing user space source code.
>
> That's indeed a problem as ILP32 doesn't look like any of the other
> options (the siginfo structure is another case that doesn't fit in any
> of the ABI as long as time_t is 64-bit).
I believe we’ve already arrived at the conclusion that timespec needs to be
changed from what Andrew and I had submitted.
Let’s go back to the underlying definition of timespec:
"The range and precision of times representable in clock_t and time_t
are
implementation-defined. The timespec structure shall contain at least
the
following members, in any order.
time_t tv_sec; // whole seconds -- >= 0
long tv_nsec; // nanoseconds -- [0, 9]”
So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
language. Any program that assumes that tv_nsec is sizeof(long) would be
correct and it would be unexpected and surprising behaviour [even though it
would be consider a good programming style] if one would need to explicitly
ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
like a good justification to do the same.
For time_t, I don’t see the need to have a 32bit type yet.
As long as the the type is properly exposed through header files (and user
programs can thus recreate the kernel’s data model), we should be safe.
Cases like the above data structure from an ioctl are clearly non-portable
and would break today on any architecture that supports ABIs with different
data models (say ILP32 and LP64)… so I would consider any attempt to
support this as trying to remain “bug-compatible”.
There are plenty of good examples in the uapi that will be nicely portable
between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this,
as the userspace library libaio uses a broken redefinition instead of the
kernel header file) as an example:
> /*
> * we always use a 64bit off_t when communicating
> * with userland. its up to libraries to do the
> * proper padding and aio_error abstraction
> */
>
> struct iocb {
> /* these are internal to the kernel/libc. */
> __u64 aio_data; /* data to be returned in event's data */
> __u32 PADDED(aio_key, aio_reserved1);
> /* the kernel sets aio_key to the req # */
>
> /* common fields */
> __u16 aio_lio_opcode; /* see IOCB_CMD_ above */
> __s16 aio_reqprio;
> __u32 aio_fildes;
>
> __u64 aio_buf;
> __u64 aio_nbytes;
> __s64 aio_offset;
>
> /* extra parameters */
> __u64 aio_reserved2; /* TODO: use this for a (struct sigevent *) */
>
> /* flags for the "struct iocb" */
> __u32 aio_flags;
>
> /*
> * if the IOCB_FLAG_RESFD flag of "aio_flags" is set, this is an
> * eventfd to signal AIO readiness to
> */
> __u32 aio_resfd;
> }; /* 64 bytes */
The key to any design decision should be that we
(a) don’t break C11, POSIX or the Single UNIX Specification
(b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
(which defines 64bit values transferable in registers to callees)
Can we thus agree on the following for the next revision of the patch-set:
(1) We retain a 64bit time_t, but implement different sizes (between ILP32 and
LP64) for ‘tv_nsec' in 'struct timespec’?
(2) We use the 64bit system calls whereever possible (i.e. no register
splitting).
Best,
Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: > For completeness, there is yet another option, which would be to use the > exact system call table from arm64 and do all the emulation in user space > rather than the kernel. This would however be the least compatible with > existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 11:51:54AM +, Pinski, Andrew wrote: > > On Apr 14, 2015, at 4:15 AM, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: > >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote: > >>> 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. > > More than that d won't work due to ucontext being different between > aarch32 and aarch64. This too, I forgot to mention it (unless we restrict ILP32 to only 15 registers, reduced FP bank; in summary, it won't work). > Also this abi is about to be used in a product so any changes need to > happen fast and need to thought out why making changes to it make > senses. This is not our problem really. It's been pretty quiet on the ILP32 front for the past 6 months or more and just because a product is going to use it is not an argument to accept a long term ABI. > Changing to use the aarch32 syscall #'s make less sense since this is > not a legacy syscalls. That I agree. I'm fine with 32-bit only data structures but I really want to stick to the asm-generic/unistd.h syscalls for new ABIs. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> > 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:
It doesn't look like they are exclusive options. For example you can use
(a) together with (c) or (d). Some more comments below:
> a) separate syscall table for arm64: as you say, this is the current approach,
>and I'd like to avoid that too
What is the problem with this option? Is it cache locality affected by
having another table? A syscall table currently stands at around 2KB. We
could halve it by storing relative offsets but I don't think we would
notice much performance improvement.
> 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
Does this mean that an ILP32 task can still call LP64-only syscalls? How
many new syscalls are we looking at? Would these ILP32 numbers be
interspersed with the LP64 ones or some high values (say bit 12 set)?
The former isn't workable since may leave gaps on LP64 architectures.
The latter could work better if the ILP32 specific options are not
sparse.
> 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
I don't fully understand this. It looks to me like we need to generate
at least the LP64 and native ILP32 unistd.h anyway if we go for option a
or possibly b.
> 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
IMO, (d) only makes sense if we treat ILP32 as a temporary solution
(a.k.a. hack) hoping that such applications will be eventually built for
LP64. If we treat native ILP32 as a real long term alternative to LP64,
I would rather use the asm-generic/unistd.h for syscalls. For example,
use 'openat' instead of 'open' on the native ILP32 (based on the
assumption that ILP32 is a long term alternative).
Unless we are aware of performance impact with (a), that's my preferred
option with some form of (b) next.
The above is mainly about syscall numbers and tables but the ABI goes
beyond this. And the key point is whether we go for an AArch32-like ABI
(32-bit time_t) or we try to define one close to LP64. If we go for an
AArch32-like ABI, we'll have to use the compat layer for some of
syscalls and assess how many of the asm/compat.h structures are
different from the generic ones (I wouldn't expect many).
> I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
> we have many drivers that today use ioctls with data structures derived from
> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
> their own data structures. These are almost all broken today, because the
> data structures are a mix of the aarch32 and aarch64 variants, while the
> ioctl() system call in ilp32 always uses the aarch32 format by default.
>
> An example here would be
>
> struct cyclades_idle_stats {
> __kernel_time_t in_use; /* Time device has been in use (secs) */
> __kernel_time_t recv_idle; /* Time since last char received (secs) */
> __kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
> unsigned long recv_bytes; /* Bytes received */
> unsigned long xmit_bytes; /* Bytes transmitted */
> unsigned long overruns;/* Input overruns */
> unsigned long frame_errs; /* Input framing errors */
> unsigned long parity_errs; /* Input parity errors */
> };
>
> for a random ancient driver. Introducing a third set of data structures
> and syscalls for aarch64-ilp32 means that any driver doing something like
> this needs to be modified to support existing user space source code.
That's indeed a problem as ILP32 doesn't look like any of the other
options (the siginfo structure is another case that doesn't fit in any
of the ABI as long as time_t is 64-bit).
> If we stick to the normal compat32 implementation for all data
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 13:50:21 Dr. Philipp Tomsich wrote: > > > On 14 Apr 2015, at 13:14, Arnd Bergmann wrote: > > > > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: > >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann 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. > > I must agree with Andrew, that (d) seems like a bad fit for ILP32… after all > the > ILP32 (ELF) ABI specifies that 64bit values are to be passed in a single > register, > but the unistd32.h assumes a 32bit kernel that receives 64bit arguments split > over two registers (i.e. the 64-variants of the various system calls, such as > ftruncate64). > > I strongly prefer (b) as this satisfies the largest number of requirements: > (i) it will be a single system call table for LP64 and ILP32 > (ii) it’s easy to be make use of the 64bit capable system calls > (iii) it fits with the relationship of ILP32 to LP64 in the ILP32 ELF ABI > definition Ok, I see. I'd still like to hear other opinions on the matter, and my preference remains D. Most importantly, I'd like Catalin and Will to comment on this. For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. > As we don’t support ILP32 without LP64, the resulting implementation will > be even simpler (i.e. no need to duplicate the entire table) than the n32 > implementation on MIPS... Right. Andrew didn't like the idea that the syscall numbers are slightly different in B, but I think that is not a significant downside, as the kernel header would be done in a way to report the correct __NR_* macros here. > >> 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. > > The glibc implementation, as we have it today, always uses the 64bit system > call > and performs overflow-checking on results (on ILP32, we can’t perform overflow > checking on arguments, as the callee needs to sign-extend). > > In other words: glibc uses the LP64 system calls and handles any pre- and > post-processing in the system-call wrappers. Hmm, that sounds like
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 10:45:43AM +, Pinski, Andrew wrote: > 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. At the time, we were not aware of plans to fix existing 32-bit architectures, so we followed Linus' similar request on x32. > The review process for the linux kernel is much harder than the review > process of gcc or even glibc now. This is not really about kernel code review but about defining the user/kernel ABI. It shouldn't even be a kernel-only decision, we need to get the libc people involved. So yes, you get to prototype such ABI in several kernel patch incarnations and code may be thrown away but that's better than making the wrong decision on the long run. As for gcc, the ILP32 ABI is clear to them, they only have to review implementation details. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann 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. Also d is worse than the rest as
you no longer default to 64bit off_t which is not a good thing. B is just as
bad and goes against using the generic syscall numbers.
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.
Thanks,
Andrew
>
On 14 Apr 2015, at 00:58, Dr. Philipp Tomsich
wrote:
2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of
adoption and in retrospect the decision to have separate system calls seems
to not have helped them. My feeling now is that if we add support for the
ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI
as close as possible and reuse the existing system call table. I realize
that this is a bit controversial, but please let's talk about this now.
>>>
>>> I see benefits and drawback to merging the system tables. Our philosophy is
>>> already somewhat different from x32 and from the original patch-series, as
>>> you
>>> can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and
>>> ‘setup_rt_frame’ functions. While these could have been duplicated and
>>> specialized for each ABI (as on x32), the attempt was made to keep these
>>> changes localized.
>>>
>>> However, this approach can not always work: if you consider cases like
>>> ‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having
>>> just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat
>>> version of the underlying system call. Having a second system call table
>>> helps to reduce the overheads in this case and keeps things readable.
>>>
>>> This comes down to the fact, that a few calls will always be different due
>>> to
>>> historical baggage in data structures shared between userspace and kernel:
>>> 'struct msgbuf’ immediatly comes to mind.
>>>
>>> I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI
>>> and
>>> its n32 ABI than to x32… but even there it’s two separate system call tables
>>> (although sequentially concatenated).
>>>
>>> In other words: I fail to see the benefit from keeping the existing table.
>>> I you elaborate on how such a solution should look, I might be better able
>>> to follow.
>
> I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
> we have many drivers that today use ioctls with data structures derived from
> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
> their own data structures. These are almost all broken today, because the
> data structures are a mix of the aarch32 and aarch64 variants, while the
> ioctl() system call in ilp32 always uses the aarch32 format by default.
>
> An example here would be
>
> struct cyclades_idle_stats {
>__kernel_time_t in_use; /* Time device
Re: [PATCH v4 00/24] ILP32 for ARM64
> On Apr 14, 2015, at 4:15 AM, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann 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. More than that d won't work due to ucontext being different between aarch32 and aarch64. I still say the current way is the best approach and is better option than the rest and it was what was agreed upon when I wrote the patch. I don't see why you are agreeing a different way. The split 64bit long was decided not to be split too, there was a previous discussion about that too. Also this abi is about to be used in a product so any changes need to happen fast and need to thought out why making changes to it make senses. Changing to use the aarch32 syscall #'s make less sense since this is not a legacy syscalls. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 14 Apr 2015, at 13:14, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann 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. I must agree with Andrew, that (d) seems like a bad fit for ILP32… after all the ILP32 (ELF) ABI specifies that 64bit values are to be passed in a single register, but the unistd32.h assumes a 32bit kernel that receives 64bit arguments split over two registers (i.e. the 64-variants of the various system calls, such as ftruncate64). I strongly prefer (b) as this satisfies the largest number of requirements: (i) it will be a single system call table for LP64 and ILP32 (ii) it’s easy to be make use of the 64bit capable system calls (iii) it fits with the relationship of ILP32 to LP64 in the ILP32 ELF ABI definition As we don’t support ILP32 without LP64, the resulting implementation will be even simpler (i.e. no need to duplicate the entire table) than the n32 implementation on MIPS... >> 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. The glibc implementation, as we have it today, always uses the 64bit system call and performs overflow-checking on results (on ILP32, we can’t perform overflow checking on arguments, as the callee needs to sign-extend). In other words: glibc uses the LP64 system calls and handles any pre- and post-processing in the system-call wrappers. >> 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. By applying the “strace-test” (i.e. “How will this affect the implementation of strace, when considering a ILP32-compiled and a LP64-compiled strace where both should be capable of tracing either ILP32 or LP64 targets?”), option (b) appears the cleanest choice, as no test on the dependent’s ABI would be necessary and all internal dispatching could be performed on syscall numbers alone. Using the same "strace-test", option (d) would be the least preferred, as it will make the internal dispatching entirely dependent on the dependent’s ABI. >> 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
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: > > On Apr 14, 2015, at 3:08 AM, Arnd Bergmann 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
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).
> > On 14 Apr 2015, at 00:58, Dr. Philipp Tomsich
> > wrote:
> >
> >> 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of
> >> adoption and in retrospect the decision to have separate system calls seems
> >> to not have helped them. My feeling now is that if we add support for the
> >> ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI
> >> as close as possible and reuse the existing system call table. I realize
> >> that this is a bit controversial, but please let's talk about this now.
> >
> > I see benefits and drawback to merging the system tables. Our philosophy is
> > already somewhat different from x32 and from the original patch-series, as
> > you
> > can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and
> > ‘setup_rt_frame’ functions. While these could have been duplicated and
> > specialized for each ABI (as on x32), the attempt was made to keep these
> > changes localized.
> >
> > However, this approach can not always work: if you consider cases like
> > ‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having
> > just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat
> > version of the underlying system call. Having a second system call table
> > helps to reduce the overheads in this case and keeps things readable.
> >
> > This comes down to the fact, that a few calls will always be different due
> > to
> > historical baggage in data structures shared between userspace and kernel:
> > 'struct msgbuf’ immediatly comes to mind.
> >
> > I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI
> > and
> > its n32 ABI than to x32… but even there it’s two separate system call tables
> > (although sequentially concatenated).
> >
> > In other words: I fail to see the benefit from keeping the existing table.
> > I you elaborate on how such a solution should look, I might be better able
> > to follow.
I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
we have many drivers that today use ioctls with data structures derived from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
If we stick to the normal compat32 implementation for all data structures
and syscalls, we can support all drivers that work with aarch32
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 00:58:59 Dr. Philipp Tomsich wrote: > Arnd, > > > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance > > burden, and we don't want to do that just because someone thinks it's a cute > > hack or because it might add a few percent in performance of some low-level > > benchmark. Please describe in the cover-letter for the patch series > > specifically what applications you have in mind that would be using this, > > and > > what the expected timeframe is before users could move to 64-bit user space. > > There’s a couple of drivers behind getting ILP32 merged on ARM64: > (a) There’s plenty of applications (i.e. having a large code-base, but not > requiring > a 64bit address space) that can’t readily be migrated to LP64 (typically > networking > or data-storage applications) because they were written assuming an ILP32 data > model. Many of these applications will never become suitable for a LP64 data > model and will remain locked into ILP32 operating environments. > (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test > cases that have been derived from large application use cases) benefit from > having a denser data-representation—this includes the mcf, xalancbmk, astar > and ometpp. This not an observation specific to ARM64 and can be observed > on other architectures as well (e.g. [1] contains data for POWER from 2010). > (c) Using AArch32 (assuming that any given ARMv8 processor supports it), > is not a real alternative, as 64bit arithmetic is not supported on AArch32 > and the > AArch32 register set is significantly smaller. Our experience shows that the > benefit of having 64bit registers, of a larger register file and of using > 64bit > arithmetic makes ILP32 a worthwhile improvement over AArch32. > > In summary, we believe that the need for ILP32 will never disappear on ARM64. > In fact, I rather expect the AArch32 compatibility to eventually disapper from > further processor designs… which will turn ILP32 into the only option for > legacy software. Ok, this is the kind of text that I was looking for to put in the cover letter, and eventually into the git changelog when the branch gets merged. Regarding a), listing specific applications would be helpful. I keep having trouble coming up with examples that fit in all these categories: - can be easily ported to a brand new CPU architecture - is complex enough to to not be portable to 64-bit - is performance sensitive enough to not work with full emulation - fits within the memory constraints of a 32-bit task a few years from now. - must run on CPUs that are explicitly designed to not support 32-bit (aarch32) tasks. I have seen a lot of legacy code, but most of it fails at one of the above. There is also a lot of legacy code (from MS Windows) that already supports LLP64 but not LP64. > > The most important aspect here I think is time_t, and while it means > > starting > > out with a system call ABI that is not ready for y2038, at the same time the > > purpose of ILP32 support is to support legacy source code that is not 64-bit > > safe now, and using 32-bit time_t will make that easier in a lot of ways. > > Note that I am also leading the effort to make 32-bit Linux ready for using > > 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it > > just won't be any better or worse than the others. > > The decision to use the 64bit time_t actually came out of Andrew’s earliest > patch-set from late 2013… we based the kernel-side of ILP32 on that one, while > we focussed on getting all the other components into a working shape. > > Breaking the C specification (by redefining time_t) always remained a > controversial issue on our end, as we knew that the day of switching back > to a 32-bit time_t would eventually have to come. Well, the reason that x32 uses a 64-bit time_t is because Linus Torvalds intervened and asked for it to be done that way. I just think that today we have a better plan for dealing with the issue on the whole. I'd definitely want to get input from other parties on this. I know that Rich Felker was particularly against the x32 definition of timespec, and it using 32-bit time_t would let us avoid the controversy for the moment, but of course we get to the same point later when we have to fix for all architectures anyway. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 00:58:59 Dr. Philipp Tomsich wrote: Arnd, 1. Adding a whole new ABI to the kernel is adding a long-term maintenance burden, and we don't want to do that just because someone thinks it's a cute hack or because it might add a few percent in performance of some low-level benchmark. Please describe in the cover-letter for the patch series specifically what applications you have in mind that would be using this, and what the expected timeframe is before users could move to 64-bit user space. There’s a couple of drivers behind getting ILP32 merged on ARM64: (a) There’s plenty of applications (i.e. having a large code-base, but not requiring a 64bit address space) that can’t readily be migrated to LP64 (typically networking or data-storage applications) because they were written assuming an ILP32 data model. Many of these applications will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments. (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test cases that have been derived from large application use cases) benefit from having a denser data-representation—this includes the mcf, xalancbmk, astar and ometpp. This not an observation specific to ARM64 and can be observed on other architectures as well (e.g. [1] contains data for POWER from 2010). (c) Using AArch32 (assuming that any given ARMv8 processor supports it), is not a real alternative, as 64bit arithmetic is not supported on AArch32 and the AArch32 register set is significantly smaller. Our experience shows that the benefit of having 64bit registers, of a larger register file and of using 64bit arithmetic makes ILP32 a worthwhile improvement over AArch32. In summary, we believe that the need for ILP32 will never disappear on ARM64. In fact, I rather expect the AArch32 compatibility to eventually disapper from further processor designs… which will turn ILP32 into the only option for legacy software. Ok, this is the kind of text that I was looking for to put in the cover letter, and eventually into the git changelog when the branch gets merged. Regarding a), listing specific applications would be helpful. I keep having trouble coming up with examples that fit in all these categories: - can be easily ported to a brand new CPU architecture - is complex enough to to not be portable to 64-bit - is performance sensitive enough to not work with full emulation - fits within the memory constraints of a 32-bit task a few years from now. - must run on CPUs that are explicitly designed to not support 32-bit (aarch32) tasks. I have seen a lot of legacy code, but most of it fails at one of the above. There is also a lot of legacy code (from MS Windows) that already supports LLP64 but not LP64. The most important aspect here I think is time_t, and while it means starting out with a system call ABI that is not ready for y2038, at the same time the purpose of ILP32 support is to support legacy source code that is not 64-bit safe now, and using 32-bit time_t will make that easier in a lot of ways. Note that I am also leading the effort to make 32-bit Linux ready for using 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it just won't be any better or worse than the others. The decision to use the 64bit time_t actually came out of Andrew’s earliest patch-set from late 2013… we based the kernel-side of ILP32 on that one, while we focussed on getting all the other components into a working shape. Breaking the C specification (by redefining time_t) always remained a controversial issue on our end, as we knew that the day of switching back to a 32-bit time_t would eventually have to come. Well, the reason that x32 uses a 64-bit time_t is because Linus Torvalds intervened and asked for it to be done that way. I just think that today we have a better plan for dealing with the issue on the whole. I'd definitely want to get input from other parties on this. I know that Rich Felker was particularly against the x32 definition of timespec, and it using 32-bit time_t would let us avoid the controversy for the moment, but of course we get to the same point later when we have to fix for all architectures anyway. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@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. Also d is worse than the rest as
you no longer default to 64bit off_t which is not a good thing. B is just as
bad and goes against using the generic syscall numbers.
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.
Thanks,
Andrew
On 14 Apr 2015, at 00:58, Dr. Philipp Tomsich
philipp.toms...@theobroma-systems.com wrote:
2. The ABI follows what x86 has their x32 ABI. This never saw a lot of
adoption and in retrospect the decision to have separate system calls seems
to not have helped them. My feeling now is that if we add support for the
ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI
as close as possible and reuse the existing system call table. I realize
that this is a bit controversial, but please let's talk about this now.
I see benefits and drawback to merging the system tables. Our philosophy is
already somewhat different from x32 and from the original patch-series, as
you
can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and
‘setup_rt_frame’ functions. While these could have been duplicated and
specialized for each ABI (as on x32), the attempt was made to keep these
changes localized.
However, this approach can not always work: if you consider cases like
‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having
just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat
version of the underlying system call. Having a second system call table
helps to reduce the overheads in this case and keeps things readable.
This comes down to the fact, that a few calls will always be different due
to
historical baggage in data structures shared between userspace and kernel:
'struct msgbuf’ immediatly comes to mind.
I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI
and
its n32 ABI than to x32… but even there it’s two separate system call tables
(although sequentially concatenated).
In other words: I fail to see the benefit from keeping the existing table.
I you elaborate on how such a solution should look, I might be better able
to follow.
I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
we have many drivers that today use ioctls with data structures derived from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since
Re: [PATCH v4 00/24] ILP32 for ARM64
On 14 Apr 2015, at 13:14, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@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. I must agree with Andrew, that (d) seems like a bad fit for ILP32… after all the ILP32 (ELF) ABI specifies that 64bit values are to be passed in a single register, but the unistd32.h assumes a 32bit kernel that receives 64bit arguments split over two registers (i.e. the 64-variants of the various system calls, such as ftruncate64). I strongly prefer (b) as this satisfies the largest number of requirements: (i) it will be a single system call table for LP64 and ILP32 (ii) it’s easy to be make use of the 64bit capable system calls (iii) it fits with the relationship of ILP32 to LP64 in the ILP32 ELF ABI definition As we don’t support ILP32 without LP64, the resulting implementation will be even simpler (i.e. no need to duplicate the entire table) than the n32 implementation on MIPS... 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. The glibc implementation, as we have it today, always uses the 64bit system call and performs overflow-checking on results (on ILP32, we can’t perform overflow checking on arguments, as the callee needs to sign-extend). In other words: glibc uses the LP64 system calls and handles any pre- and post-processing in the system-call wrappers. 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. By applying the “strace-test” (i.e. “How will this affect the implementation of strace, when considering a ILP32-compiled and a LP64-compiled strace where both should be capable of tracing either ILP32 or LP64 targets?”), option (b) appears the cleanest choice, as no test on the dependent’s ABI would be necessary and all internal dispatching could be performed on syscall numbers alone. Using the same strace-test, option (d) would be the least preferred, as it will make the internal dispatching entirely dependent on the dependent’s ABI. 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
Re: [PATCH v4 00/24] ILP32 for ARM64
On Apr 14, 2015, at 4:15 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@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. More than that d won't work due to ucontext being different between aarch32 and aarch64. I still say the current way is the best approach and is better option than the rest and it was what was agreed upon when I wrote the patch. I don't see why you are agreeing a different way. The split 64bit long was decided not to be split too, there was a previous discussion about that too. Also this abi is about to be used in a product so any changes need to happen fast and need to thought out why making changes to it make senses. Changing to use the aarch32 syscall #'s make less sense since this is not a legacy syscalls. 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
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).
On 14 Apr 2015, at 00:58, Dr. Philipp Tomsich
philipp.toms...@theobroma-systems.com wrote:
2. The ABI follows what x86 has their x32 ABI. This never saw a lot of
adoption and in retrospect the decision to have separate system calls seems
to not have helped them. My feeling now is that if we add support for the
ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI
as close as possible and reuse the existing system call table. I realize
that this is a bit controversial, but please let's talk about this now.
I see benefits and drawback to merging the system tables. Our philosophy is
already somewhat different from x32 and from the original patch-series, as
you
can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and
‘setup_rt_frame’ functions. While these could have been duplicated and
specialized for each ABI (as on x32), the attempt was made to keep these
changes localized.
However, this approach can not always work: if you consider cases like
‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having
just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat
version of the underlying system call. Having a second system call table
helps to reduce the overheads in this case and keeps things readable.
This comes down to the fact, that a few calls will always be different due
to
historical baggage in data structures shared between userspace and kernel:
'struct msgbuf’ immediatly comes to mind.
I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI
and
its n32 ABI than to x32… but even there it’s two separate system call tables
(although sequentially concatenated).
In other words: I fail to see the benefit from keeping the existing table.
I you elaborate on how such a solution should look, I might be better able
to follow.
I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
we have many drivers that today use ioctls with data structures derived from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
If we stick to the normal compat32 implementation for all data structures
and syscalls, we can support all drivers that work with aarch32 emulation
today, as well as any one that gains support later on a
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 10:45:43AM +, Pinski, Andrew wrote: 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. At the time, we were not aware of plans to fix existing 32-bit architectures, so we followed Linus' similar request on x32. The review process for the linux kernel is much harder than the review process of gcc or even glibc now. This is not really about kernel code review but about defining the user/kernel ABI. It shouldn't even be a kernel-only decision, we need to get the libc people involved. So yes, you get to prototype such ABI in several kernel patch incarnations and code may be thrown away but that's better than making the wrong decision on the long run. As for gcc, the ILP32 ABI is clear to them, they only have to review implementation details. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com wrote:
I mainly want to avoid accidentally creating new ABIs for syscalls and
ioctls:
we have many drivers that today use ioctls with data structures derived
from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs)
*/
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
That's indeed a problem as ILP32 doesn't look like any of the other
options (the siginfo structure is another case that doesn't fit in any
of the ABI as long as time_t is 64-bit).
I believe we’ve already arrived at the conclusion that timespec needs to be
changed from what Andrew and I had submitted.
Let’s go back to the underlying definition of timespec:
The range and precision of times representable in clock_t and time_t
are
implementation-defined. The timespec structure shall contain at least
the
following members, in any order.
time_t tv_sec; // whole seconds -- = 0
long tv_nsec; // nanoseconds -- [0, 9]”
So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
language. Any program that assumes that tv_nsec is sizeof(long) would be
correct and it would be unexpected and surprising behaviour [even though it
would be consider a good programming style] if one would need to explicitly
ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
like a good justification to do the same.
From a standards perspective, that's clear, and I'm fine with not making
the same choice as x32. I think on x32 it was a side-effect of glibc
defining tv_nsec as __syscall_slong_t and the kernel defining
__kernel_long_t to 64-bit.
For time_t, I don’t see the need to have a 32bit type yet.
As long as the the type is properly exposed through header files (and user
programs can thus recreate the kernel’s data model), we should be safe.
The problem with a 64-bit time_t is that the timespec structure looks
like neither compat32 nor native 64-bit. If we make the AArch32 and
native ILP32 exclusive and build time, it makes it easier, otherwise we
need to support a third ABI in the kernel.
The key to any design decision should be that we
(a) don’t break C11, POSIX or the Single UNIX Specification
(b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
(which defines 64bit values transferable in registers to callees)
I think these are fine.
Can we thus agree on the following for the next revision of the patch-set:
(1) We retain a 64bit time_t, but implement different sizes (between ILP32
and
LP64) for ‘tv_nsec' in 'struct timespec’?
(2) We use the 64bit system calls whereever possible (i.e. no register
splitting).
As I mentioned above, timespec and possibly other structures no longer
like any of the existing ABIs. Do we know how many syscalls are
affected?
The alternative is 32-bit time_t which makes it easier to use the compat
syscall implementations (not numbers). It also depends on how we plan to
fix the 2038 problem. For new 32-bit only architectures, are we going to
require them to use a 64-bit time_t or we get alternative time64_t and
timespec64 specs?
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
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:
It doesn't look like they are exclusive options. For example you can use
(a) together with (c) or (d). Some more comments below:
a) separate syscall table for arm64: as you say, this is the current approach,
and I'd like to avoid that too
What is the problem with this option? Is it cache locality affected by
having another table? A syscall table currently stands at around 2KB. We
could halve it by storing relative offsets but I don't think we would
notice much performance improvement.
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
Does this mean that an ILP32 task can still call LP64-only syscalls? How
many new syscalls are we looking at? Would these ILP32 numbers be
interspersed with the LP64 ones or some high values (say bit 12 set)?
The former isn't workable since may leave gaps on LP64 architectures.
The latter could work better if the ILP32 specific options are not
sparse.
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
I don't fully understand this. It looks to me like we need to generate
at least the LP64 and native ILP32 unistd.h anyway if we go for option a
or possibly b.
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
IMO, (d) only makes sense if we treat ILP32 as a temporary solution
(a.k.a. hack) hoping that such applications will be eventually built for
LP64. If we treat native ILP32 as a real long term alternative to LP64,
I would rather use the asm-generic/unistd.h for syscalls. For example,
use 'openat' instead of 'open' on the native ILP32 (based on the
assumption that ILP32 is a long term alternative).
Unless we are aware of performance impact with (a), that's my preferred
option with some form of (b) next.
The above is mainly about syscall numbers and tables but the ABI goes
beyond this. And the key point is whether we go for an AArch32-like ABI
(32-bit time_t) or we try to define one close to LP64. If we go for an
AArch32-like ABI, we'll have to use the compat layer for some of
syscalls and assess how many of the asm/compat.h structures are
different from the generic ones (I wouldn't expect many).
I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls:
we have many drivers that today use ioctls with data structures derived from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
That's indeed a problem as ILP32 doesn't look like any of the other
options (the siginfo structure is another case that doesn't fit in any
of the ABI as long as time_t is 64-bit).
If we stick to the normal compat32 implementation for all data structures
and syscalls, we can support all drivers that work with aarch32
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tue, Apr 14, 2015 at 11:51:54AM +, Pinski, Andrew wrote: On Apr 14, 2015, at 4:15 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de wrote: 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. More than that d won't work due to ucontext being different between aarch32 and aarch64. This too, I forgot to mention it (unless we restrict ILP32 to only 15 registers, reduced FP bank; in summary, it won't work). Also this abi is about to be used in a product so any changes need to happen fast and need to thought out why making changes to it make senses. This is not our problem really. It's been pretty quiet on the ILP32 front for the past 6 months or more and just because a product is going to use it is not an argument to accept a long term ABI. Changing to use the aarch32 syscall #'s make less sense since this is not a legacy syscalls. That I agree. I'm fine with 32-bit only data structures but I really want to stick to the asm-generic/unistd.h syscalls for new ABIs. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote:
On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
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:
It doesn't look like they are exclusive options. For example you can use
(a) together with (c) or (d). Some more comments below:
I meant them to be exclusive, but you are right that the list
was not complete, and it's possible to interpret it different
from what I had in mind.
a) separate syscall table for arm64: as you say, this is the current
approach,
and I'd like to avoid that too
What is the problem with this option? Is it cache locality affected by
having another table? A syscall table currently stands at around 2KB. We
could halve it by storing relative offsets but I don't think we would
notice much performance improvement.
No, I'm not worried about performance here, the main differences to b) and c)
here is that you have to maintain this list, and potentially duplicate it
for new 64-bit architectures coming in (x86, mips etc already have separate
copies, so that ship has sailed). I'd rather see that table being maintained
in asm-generic as architecture independent code than in arch/arm64.
The much bigger problem of data structures that are incompatible with both
existing ABIs is shared with approach b and c.
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
Does this mean that an ILP32 task can still call LP64-only syscalls? How
many new syscalls are we looking at? Would these ILP32 numbers be
interspersed with the LP64 ones or some high values (say bit 12 set)?
The former isn't workable since may leave gaps on LP64 architectures.
The latter could work better if the ILP32 specific options are not
sparse.
This would be the same list that patch 19/24 of this series adds, 32
system calls in total, possibly a few more getting added over the
years.
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
I don't fully understand this. It looks to me like we need to generate
at least the LP64 and native ILP32 unistd.h anyway if we go for option a
or possibly b.
With option b), we'd generate one table from asm-generic/unistd.h and
another one from asm/unistd32.h, as we do today. The first would be
shared between both aarch64 ABIs (and extended with 32 new calls) while
the second continues unmodified.
With option c), we'd use the asm-generic/unistd.h source to generate
two independent tables, similar to what we do in
arch/tile/kernel/{sys,compat}.c, and the first table would be the same
as it is 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
IMO, (d) only makes sense if we treat ILP32 as a temporary solution
(a.k.a. hack) hoping that such applications will be eventually built for
LP64. If we treat native ILP32 as a real long term alternative to LP64,
I would rather use the asm-generic/unistd.h for syscalls. For example,
use 'openat' instead of 'open' on the native ILP32 (based on the
assumption that ILP32 is a long term alternative).
Unless we are aware of performance impact with (a), that's my preferred
option with some form of (b) next.
Ok, let's call that option
e) Use the existing aarch32 data structures with the asm-generic/unistd.h
system call numbers.
This would solve the main problem of the data structures just like option
d), and the main user-visible change would be that the syscall numbers
are shifted compared to aarch32, which is a very minor aspect. We could
also deal with the ucontext better this way than what I suggested.
The above is mainly about syscall numbers and tables but the ABI goes
beyond this. And the key point is whether we go for an AArch32-like ABI
(32-bit time_t) or we try to define one close to LP64. If
Re: [PATCH v4 00/24] ILP32 for ARM64
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com wrote:
I mainly want to avoid accidentally creating new ABIs for syscalls and
ioctls:
we have many drivers that today use ioctls with data structures derived from
'__kernel_ulong_t' in some form, often by including a timespec or time_t in
their own data structures. These are almost all broken today, because the
data structures are a mix of the aarch32 and aarch64 variants, while the
ioctl() system call in ilp32 always uses the aarch32 format by default.
An example here would be
struct cyclades_idle_stats {
__kernel_time_t in_use; /* Time device has been in use (secs) */
__kernel_time_t recv_idle; /* Time since last char received (secs) */
__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
unsigned long recv_bytes; /* Bytes received */
unsigned long xmit_bytes; /* Bytes transmitted */
unsigned long overruns;/* Input overruns */
unsigned long frame_errs; /* Input framing errors */
unsigned long parity_errs; /* Input parity errors */
};
for a random ancient driver. Introducing a third set of data structures
and syscalls for aarch64-ilp32 means that any driver doing something like
this needs to be modified to support existing user space source code.
That's indeed a problem as ILP32 doesn't look like any of the other
options (the siginfo structure is another case that doesn't fit in any
of the ABI as long as time_t is 64-bit).
I believe we’ve already arrived at the conclusion that timespec needs to be
changed from what Andrew and I had submitted.
Let’s go back to the underlying definition of timespec:
The range and precision of times representable in clock_t and time_t
are
implementation-defined. The timespec structure shall contain at least
the
following members, in any order.
time_t tv_sec; // whole seconds -- = 0
long tv_nsec; // nanoseconds -- [0, 9]”
So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
language. Any program that assumes that tv_nsec is sizeof(long) would be
correct and it would be unexpected and surprising behaviour [even though it
would be consider a good programming style] if one would need to explicitly
ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
like a good justification to do the same.
For time_t, I don’t see the need to have a 32bit type yet.
As long as the the type is properly exposed through header files (and user
programs can thus recreate the kernel’s data model), we should be safe.
Cases like the above data structure from an ioctl are clearly non-portable
and would break today on any architecture that supports ABIs with different
data models (say ILP32 and LP64)… so I would consider any attempt to
support this as trying to remain “bug-compatible”.
There are plenty of good examples in the uapi that will be nicely portable
between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this,
as the userspace library libaio uses a broken redefinition instead of the
kernel header file) as an example:
/*
* we always use a 64bit off_t when communicating
* with userland. its up to libraries to do the
* proper padding and aio_error abstraction
*/
struct iocb {
/* these are internal to the kernel/libc. */
__u64 aio_data; /* data to be returned in event's data */
__u32 PADDED(aio_key, aio_reserved1);
/* the kernel sets aio_key to the req # */
/* common fields */
__u16 aio_lio_opcode; /* see IOCB_CMD_ above */
__s16 aio_reqprio;
__u32 aio_fildes;
__u64 aio_buf;
__u64 aio_nbytes;
__s64 aio_offset;
/* extra parameters */
__u64 aio_reserved2; /* TODO: use this for a (struct sigevent *) */
/* flags for the struct iocb */
__u32 aio_flags;
/*
* if the IOCB_FLAG_RESFD flag of aio_flags is set, this is an
* eventfd to signal AIO readiness to
*/
__u32 aio_resfd;
}; /* 64 bytes */
The key to any design decision should be that we
(a) don’t break C11, POSIX or the Single UNIX Specification
(b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
(which defines 64bit values transferable in registers to callees)
Can we thus agree on the following for the next revision of the patch-set:
(1) We retain a 64bit time_t, but implement different sizes (between ILP32 and
LP64) for ‘tv_nsec' in 'struct timespec’?
(2) We use the 64bit system calls whereever possible (i.e. no register
splitting).
Best,
Phil.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 13:50:21 Dr. Philipp Tomsich wrote: On 14 Apr 2015, at 13:14, Arnd Bergmann a...@arndb.de wrote: On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@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. I must agree with Andrew, that (d) seems like a bad fit for ILP32… after all the ILP32 (ELF) ABI specifies that 64bit values are to be passed in a single register, but the unistd32.h assumes a 32bit kernel that receives 64bit arguments split over two registers (i.e. the 64-variants of the various system calls, such as ftruncate64). I strongly prefer (b) as this satisfies the largest number of requirements: (i) it will be a single system call table for LP64 and ILP32 (ii) it’s easy to be make use of the 64bit capable system calls (iii) it fits with the relationship of ILP32 to LP64 in the ILP32 ELF ABI definition Ok, I see. I'd still like to hear other opinions on the matter, and my preference remains D. Most importantly, I'd like Catalin and Will to comment on this. For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. As we don’t support ILP32 without LP64, the resulting implementation will be even simpler (i.e. no need to duplicate the entire table) than the n32 implementation on MIPS... Right. Andrew didn't like the idea that the syscall numbers are slightly different in B, but I think that is not a significant downside, as the kernel header would be done in a way to report the correct __NR_* macros here. 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. The glibc implementation, as we have it today, always uses the 64bit system call and performs overflow-checking on results (on ILP32, we can’t perform overflow checking on arguments, as the callee needs to sign-extend). In other words: glibc uses the LP64 system calls and handles any pre- and post-processing in the system-call wrappers. Hmm, that sounds like much more work you already do in glibc than you'd need to split up the 64-bit arguments for the eight syscalls that pass an loff_t in a register. B is just as bad and goes against using the generic syscall numbers. How so? The newly
Re: [PATCH v4 00/24] ILP32 for ARM64
On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: For completeness, there is yet another option, which would be to use the exact system call table from arm64 and do all the emulation in user space rather than the kernel. This would however be the least compatible with existing source code, so you probably don't want to do that. It would be great if this worked but I think we looked at it before and it seems nice until you hit the futex stuff and robust lists (I don't fully remember the details). Some of the structures (siginfo) would no longer be POSIX compliant and some of them aren't only accessed via libc to be able to create shadow copies. Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to enable a very special class of applications, it's not like anyone would want to run a full system for this and need POSIX compliance. We could definitely be pragmatic and do whatever helps get the job done. That said, it diverges further from what legacy 32-bit applications expect to see, so this approach will likely make an application port harder, not easier. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Arnd, > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance > burden, and we don't want to do that just because someone thinks it's a cute > hack or because it might add a few percent in performance of some low-level > benchmark. Please describe in the cover-letter for the patch series > specifically what applications you have in mind that would be using this, and > what the expected timeframe is before users could move to 64-bit user space. There’s a couple of drivers behind getting ILP32 merged on ARM64: (a) There’s plenty of applications (i.e. having a large code-base, but not requiring a 64bit address space) that can’t readily be migrated to LP64 (typically networking or data-storage applications) because they were written assuming an ILP32 data model. Many of these applications will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments. (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test cases that have been derived from large application use cases) benefit from having a denser data-representation—this includes the mcf, xalancbmk, astar and ometpp. This not an observation specific to ARM64 and can be observed on other architectures as well (e.g. [1] contains data for POWER from 2010). (c) Using AArch32 (assuming that any given ARMv8 processor supports it), is not a real alternative, as 64bit arithmetic is not supported on AArch32 and the AArch32 register set is significantly smaller. Our experience shows that the benefit of having 64bit registers, of a larger register file and of using 64bit arithmetic makes ILP32 a worthwhile improvement over AArch32. In summary, we believe that the need for ILP32 will never disappear on ARM64. In fact, I rather expect the AArch32 compatibility to eventually disapper from further processor designs… which will turn ILP32 into the only option for legacy software. > 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of > adoption and in retrospect the decision to have separate system calls seems > to not have helped them. My feeling now is that if we add support for the > ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI > as close as possible and reuse the existing system call table. I realize > that this is a bit controversial, but please let's talk about this now. I see benefits and drawback to merging the system tables. Our philosophy is already somewhat different from x32 and from the original patch-series, as you can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and ‘setup_rt_frame’ functions. While these could have been duplicated and specialized for each ABI (as on x32), the attempt was made to keep these changes localized. However, this approach can not always work: if you consider cases like ‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat version of the underlying system call. Having a second system call table helps to reduce the overheads in this case and keeps things readable. This comes down to the fact, that a few calls will always be different due to historical baggage in data structures shared between userspace and kernel: 'struct msgbuf’ immediatly comes to mind. I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI and its n32 ABI than to x32… but even there it’s two separate system call tables (although sequentially concatenated). In other words: I fail to see the benefit from keeping the existing table. I you elaborate on how such a solution should look, I might be better able to follow. > The most important aspect here I think is time_t, and while it means starting > out with a system call ABI that is not ready for y2038, at the same time the > purpose of ILP32 support is to support legacy source code that is not 64-bit > safe now, and using 32-bit time_t will make that easier in a lot of ways. > Note that I am also leading the effort to make 32-bit Linux ready for using > 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it > just won't be any better or worse than the others. The decision to use the 64bit time_t actually came out of Andrew’s earliest patch-set from late 2013… we based the kernel-side of ILP32 on that one, while we focussed on getting all the other components into a working shape. Breaking the C specification (by redefining time_t) always remained a controversial issue on our end, as we knew that the day of switching back to a 32-bit time_t would eventually have to come. Cheers, Phil. [1] https://gcc.gnu.org/wiki/summit2010?action=AttachFile=get=meissner2.pdf-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH v4 00/24] ILP32 for ARM64
On Monday 13 April 2015 21:44:10 Philipp Tomsich wrote: > If anybody wants to rerun LTP, let me know, so I can provide a > buildroot-generated rootfs-image via FTP. > > The key differences from earlier changesets are: > * updated to 4.0 > * fixes for functions using 'struct msgbuf' (using compat) > * deduplication of code by using a 32bit stack_t (using compat) > * updated the documentation to clarify the changes to stack_t > * introduced a sub-architecture (via COMPAT_ELF_PLATFORM) to make >life easier for tools (e.g. gdb) when attaching to a live process >(a corefile is easily distinguishable by being ELFCLASS32). > > Any review comments are welcome. Hi Philipp, Thanks for picking up these patches again. I have had a lot of conversations about them recently, and have two very broad issues that we need to resolve before merging them: 1. Adding a whole new ABI to the kernel is adding a long-term maintenance burden, and we don't want to do that just because someone thinks it's a cute hack or because it might add a few percent in performance of some low-level benchmark. Please describe in the cover-letter for the patch series specifically what applications you have in mind that would be using this, and what the expected timeframe is before users could move to 64-bit user space. 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of adoption and in retrospect the decision to have separate system calls seems to not have helped them. My feeling now is that if we add support for the ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI as close as possible and reuse the existing system call table. I realize that this is a bit controversial, but please let's talk about this now. The most important aspect here I think is time_t, and while it means starting out with a system call ABI that is not ready for y2038, at the same time the purpose of ILP32 support is to support legacy source code that is not 64-bit safe now, and using 32-bit time_t will make that easier in a lot of ways. Note that I am also leading the effort to make 32-bit Linux ready for using 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it just won't be any better or worse than the others. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/24] ILP32 for ARM64
This is an updated version of Andrew Pinski's ILP32 patch-series for ARM64
(see https://lkml.org/lkml/2014/9/3/704) which merges some changes from our
implementation of ILP32 with his.
I made sure to have Andrew as an author, wherever no significant
changes to his patches occurred and updated the author field on the
others, so it's easier for reviewers (and for Andrew) to track what
changed and what did not... we've also tried to address as outstanding
review comments against those patches if we were aware of those (as a
result and an exception to the aforementioned rule, some of original patches
may have been updated, even if we the below list doesn't make it apparent).
Note that we didn't resort to changing the time_t definition to 32bit for
ILP32 (related to https://sourceware.org/bugzilla/show_bug.cgi?id=16437).
This patch-series has been verified using LTP in a buildroot-environment
with no unexpected fails (note, that the io_submit test currently fails,
as we haven't updated the userspace data-structures in libaio for ILP32,
yet). There's a full set of matching changes to binutils, gdb, gcc, glibc,
strace, LTP and openssl (probably other packages,too) to be submitted, once
we have the kernel-level ABI changes committed.
If anybody wants to rerun LTP, let me know, so I can provide a
buildroot-generated rootfs-image via FTP.
The key differences from earlier changesets are:
* updated to 4.0
* fixes for functions using 'struct msgbuf' (using compat)
* deduplication of code by using a 32bit stack_t (using compat)
* updated the documentation to clarify the changes to stack_t
* introduced a sub-architecture (via COMPAT_ELF_PLATFORM) to make
life easier for tools (e.g. gdb) when attaching to a live process
(a corefile is easily distinguishable by being ELFCLASS32).
Any review comments are welcome.
--Phil.
Andrew Pinski (18):
arm64: ensure the kernel is compiled for LP64
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0
instead
arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64:ilp32: share signal structures between ILP32 and LP64 ABIs
arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit
registers
arm64:ilp32: use non-compat syscall names for ILP32 as for LP64
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64:ilp32: share HWCAP between LP64 and ILP32
arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads
arm64:ilp32: support core dump generation for ILP32
arm64: add support for starting ILP32 (ELFCLASS32) binaries
ptrace: Allow compat to use the native siginfo
arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64:ilp32: use the native siginfo instead of the compat siginfo
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (6):
arm64:ilp32: add documentation on the ILP32 ABI for ARM64
arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks
arm64:ilp32: add vdso-ilp32 and use for signal return
arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32
arm64:ilp32: use compat for stack_t
arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for
ILP32
Documentation/arm64/ilp32.txt | 64
arch/arm64/Kconfig| 15 ++-
arch/arm64/Makefile | 4 +
arch/arm64/include/asm/compat.h | 65 +++-
arch/arm64/include/asm/elf.h | 105 +---
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/hwcap.h| 12 ++-
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/include/asm/processor.h| 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/signal32.h | 2 +
arch/arm64/include/asm/stat.h | 2 +
arch/arm64/include/asm/thread_info.h | 3 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 4 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/posix_types.h | 12 ++-
arch/arm64/include/uapi/asm/siginfo.h | 21
arch/arm64/include/uapi/asm/signal.h | 32 ++
arch/arm64/include/uapi/asm/unistd.h | 7 ++
arch/arm64/kernel/Makefile| 8 +-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 18 +++-
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 6 +-
arch/arm64/kernel/process.c | 6 +-
arch/arm64/kernel/ptrace.c| 49 ++---
arch/arm64/kernel/signal.c
[PATCH v4 00/24] ILP32 for ARM64
This is an updated version of Andrew Pinski's ILP32 patch-series for ARM64
(see https://lkml.org/lkml/2014/9/3/704) which merges some changes from our
implementation of ILP32 with his.
I made sure to have Andrew as an author, wherever no significant
changes to his patches occurred and updated the author field on the
others, so it's easier for reviewers (and for Andrew) to track what
changed and what did not... we've also tried to address as outstanding
review comments against those patches if we were aware of those (as a
result and an exception to the aforementioned rule, some of original patches
may have been updated, even if we the below list doesn't make it apparent).
Note that we didn't resort to changing the time_t definition to 32bit for
ILP32 (related to https://sourceware.org/bugzilla/show_bug.cgi?id=16437).
This patch-series has been verified using LTP in a buildroot-environment
with no unexpected fails (note, that the io_submit test currently fails,
as we haven't updated the userspace data-structures in libaio for ILP32,
yet). There's a full set of matching changes to binutils, gdb, gcc, glibc,
strace, LTP and openssl (probably other packages,too) to be submitted, once
we have the kernel-level ABI changes committed.
If anybody wants to rerun LTP, let me know, so I can provide a
buildroot-generated rootfs-image via FTP.
The key differences from earlier changesets are:
* updated to 4.0
* fixes for functions using 'struct msgbuf' (using compat)
* deduplication of code by using a 32bit stack_t (using compat)
* updated the documentation to clarify the changes to stack_t
* introduced a sub-architecture (via COMPAT_ELF_PLATFORM) to make
life easier for tools (e.g. gdb) when attaching to a live process
(a corefile is easily distinguishable by being ELFCLASS32).
Any review comments are welcome.
--Phil.
Andrew Pinski (18):
arm64: ensure the kernel is compiled for LP64
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0
instead
arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64:ilp32: share signal structures between ILP32 and LP64 ABIs
arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit
registers
arm64:ilp32: use non-compat syscall names for ILP32 as for LP64
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64:ilp32: share HWCAP between LP64 and ILP32
arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads
arm64:ilp32: support core dump generation for ILP32
arm64: add support for starting ILP32 (ELFCLASS32) binaries
ptrace: Allow compat to use the native siginfo
arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64:ilp32: use the native siginfo instead of the compat siginfo
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (6):
arm64:ilp32: add documentation on the ILP32 ABI for ARM64
arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks
arm64:ilp32: add vdso-ilp32 and use for signal return
arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32
arm64:ilp32: use compat for stack_t
arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for
ILP32
Documentation/arm64/ilp32.txt | 64
arch/arm64/Kconfig| 15 ++-
arch/arm64/Makefile | 4 +
arch/arm64/include/asm/compat.h | 65 +++-
arch/arm64/include/asm/elf.h | 105 +---
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/hwcap.h| 12 ++-
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/include/asm/processor.h| 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/signal32.h | 2 +
arch/arm64/include/asm/stat.h | 2 +
arch/arm64/include/asm/thread_info.h | 3 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 4 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/posix_types.h | 12 ++-
arch/arm64/include/uapi/asm/siginfo.h | 21
arch/arm64/include/uapi/asm/signal.h | 32 ++
arch/arm64/include/uapi/asm/unistd.h | 7 ++
arch/arm64/kernel/Makefile| 8 +-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 18 +++-
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 6 +-
arch/arm64/kernel/process.c | 6 +-
arch/arm64/kernel/ptrace.c| 49 ++---
arch/arm64/kernel/signal.c
