Re: [PATCH v5 00/23] ILP32 for ARM64

[Pinski, Andrew]

> On Oct 5, 2015, at 8:59 AM, Catalin Marinas  wrote:
> 
>> On Sat, Oct 03, 2015 at 02:18:57AM +, Kapoor, Prasun wrote:
>>> On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:
>>> So, at the time, following x32 discussions, we thought of using the
>>> native ABI as much as possible. However, two important things happened
>>> since:
>>> 
>>> 1. libc community didn't like breaking the POSIX compliance
>>> 2. No-one seems desperate for ILP32 on AArch64
>>> 
>>> (1) is a fair point and I would rather be careful as we don't know the
>>> extent of the code affected. In the meantime, we've also had ongoing
>>> work for addressing the 2038 issue on 32-bit architectures.
>>> 
>>> The second point is equally important. The benchmarks I've seen didn't
>>> show a significant improvement and the messages I got on various
>>> channels pretty much labeled ILP32 as a transitional stage to full LP64.
>>> In this case, we need to balance the benefits of a close to native ABI
>>> (future proof, slightly higher performance) vs. the cost of maintaining
>>> such ABI in the kernel on the long term, especially if it's not widely
>>> used/tested.
>> 
>> For us ILP32  is not about putting this into our product flier at all, it
>> is about supporting real applications. We have an existing product line of
>> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
>> applications are currently in production. Our customers are looking to
>> bring those applications (mostly in Networking and Telecom space) over to
>> ARMv8. 
>> 
>> We think its an extremely risky strategy to say either future processors
>> should incur the additional cost (power and complexity) of implementing
>> Aarch32 instruction set or have no way of  supporting 32 bit applications
>> at all.
> 
> Well, given that Cavium posted only 3 versions of this series since
> September 2013, it doesn't seem critical at all.

We are going to post another version as soon as we finish the changes that you 
requested this time around. I am working on the glibc and yury (with my help) 
will doing the kernel side. 


> 
>> Apart from there being an installed base of 32 bit networking and telecom
>> applications, we have also seen non-trivial performance gains with ILP32
>> (for example, our SPECINT score goes up by 7% with ILP32 compared to
>> LP64).
> 
> It would be good to re-run the benchmarks with the latest gcc since
> LP64/AArch64 support has evolved in the meantime.

We are also rerunning the numbers with the latest released gcc (5.2) and will 
report results when we submit the next version of the patch set.  

Thanks,
Andrew

> 
> -- 
> 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 v5 00/23] ILP32 for ARM64

[Yury Norov]

On Fri, Oct 02, 2015 at 12:49:46AM +0300, Pinski, Andrew wrote:

[...]

> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and
> redo the toolchain support for them.  Note this is going back to the abi
> I had originally done when I submitted my original version when it was
> asked to change time_t to be 64bit. 
> 
> Thanks,
> Andrew

Hi Andrew,

I try to apply your glibc ILP32 patchset on current glibc master, but
there're many merge failures.
https://sourceware.org/ml/libc-alpha/2014-10/msg00596.html

Could you share more fresh version of it, if you have one?

Are there any special commands or configure options needed 
to enable ILP32 properly?

BR,
Yury.
--
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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Sat, Oct 03, 2015 at 02:18:57AM +, Kapoor, Prasun wrote:
> On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:
> >So, at the time, following x32 discussions, we thought of using the
> >native ABI as much as possible. However, two important things happened
> >since:
> >
> >1. libc community didn't like breaking the POSIX compliance
> >2. No-one seems desperate for ILP32 on AArch64
> >
> >(1) is a fair point and I would rather be careful as we don't know the
> >extent of the code affected. In the meantime, we've also had ongoing
> >work for addressing the 2038 issue on 32-bit architectures.
> >
> >The second point is equally important. The benchmarks I've seen didn't
> >show a significant improvement and the messages I got on various
> >channels pretty much labeled ILP32 as a transitional stage to full LP64.
> >In this case, we need to balance the benefits of a close to native ABI
> >(future proof, slightly higher performance) vs. the cost of maintaining
> >such ABI in the kernel on the long term, especially if it's not widely
> >used/tested.
> 
> For us ILP32  is not about putting this into our product flier at all, it
> is about supporting real applications. We have an existing product line of
> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
> applications are currently in production. Our customers are looking to
> bring those applications (mostly in Networking and Telecom space) over to
> ARMv8. 
> 
> We think its an extremely risky strategy to say either future processors
> should incur the additional cost (power and complexity) of implementing
> Aarch32 instruction set or have no way of  supporting 32 bit applications
> at all.

Well, given that Cavium posted only 3 versions of this series since
September 2013, it doesn't seem critical at all.

> Apart from there being an installed base of 32 bit networking and telecom
> applications, we have also seen non-trivial performance gains with ILP32
> (for example, our SPECINT score goes up by 7% with ILP32 compared to
> LP64).

It would be good to re-run the benchmarks with the latest gcc since
LP64/AArch64 support has evolved in the meantime.

-- 
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 v5 00/23] ILP32 for ARM64

[Yury Norov]

On Fri, Oct 02, 2015 at 12:49:46AM +0300, Pinski, Andrew wrote:

[...]

> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and
> redo the toolchain support for them.  Note this is going back to the abi
> I had originally done when I submitted my original version when it was
> asked to change time_t to be 64bit. 
> 
> Thanks,
> Andrew

Hi Andrew,

I try to apply your glibc ILP32 patchset on current glibc master, but
there're many merge failures.
https://sourceware.org/ml/libc-alpha/2014-10/msg00596.html

Could you share more fresh version of it, if you have one?

Are there any special commands or configure options needed 
to enable ILP32 properly?

BR,
Yury.
--
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 v5 00/23] ILP32 for ARM64

[Pinski, Andrew]

> On Oct 5, 2015, at 8:59 AM, Catalin Marinas  wrote:
> 
>> On Sat, Oct 03, 2015 at 02:18:57AM +, Kapoor, Prasun wrote:
>>> On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:
>>> So, at the time, following x32 discussions, we thought of using the
>>> native ABI as much as possible. However, two important things happened
>>> since:
>>> 
>>> 1. libc community didn't like breaking the POSIX compliance
>>> 2. No-one seems desperate for ILP32 on AArch64
>>> 
>>> (1) is a fair point and I would rather be careful as we don't know the
>>> extent of the code affected. In the meantime, we've also had ongoing
>>> work for addressing the 2038 issue on 32-bit architectures.
>>> 
>>> The second point is equally important. The benchmarks I've seen didn't
>>> show a significant improvement and the messages I got on various
>>> channels pretty much labeled ILP32 as a transitional stage to full LP64.
>>> In this case, we need to balance the benefits of a close to native ABI
>>> (future proof, slightly higher performance) vs. the cost of maintaining
>>> such ABI in the kernel on the long term, especially if it's not widely
>>> used/tested.
>> 
>> For us ILP32  is not about putting this into our product flier at all, it
>> is about supporting real applications. We have an existing product line of
>> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
>> applications are currently in production. Our customers are looking to
>> bring those applications (mostly in Networking and Telecom space) over to
>> ARMv8. 
>> 
>> We think its an extremely risky strategy to say either future processors
>> should incur the additional cost (power and complexity) of implementing
>> Aarch32 instruction set or have no way of  supporting 32 bit applications
>> at all.
> 
> Well, given that Cavium posted only 3 versions of this series since
> September 2013, it doesn't seem critical at all.

We are going to post another version as soon as we finish the changes that you 
requested this time around. I am working on the glibc and yury (with my help) 
will doing the kernel side. 


> 
>> Apart from there being an installed base of 32 bit networking and telecom
>> applications, we have also seen non-trivial performance gains with ILP32
>> (for example, our SPECINT score goes up by 7% with ILP32 compared to
>> LP64).
> 
> It would be good to re-run the benchmarks with the latest gcc since
> LP64/AArch64 support has evolved in the meantime.

We are also rerunning the numbers with the latest released gcc (5.2) and will 
report results when we submit the next version of the patch set.  

Thanks,
Andrew

> 
> -- 
> 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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Sat, Oct 03, 2015 at 02:18:57AM +, Kapoor, Prasun wrote:
> On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:
> >So, at the time, following x32 discussions, we thought of using the
> >native ABI as much as possible. However, two important things happened
> >since:
> >
> >1. libc community didn't like breaking the POSIX compliance
> >2. No-one seems desperate for ILP32 on AArch64
> >
> >(1) is a fair point and I would rather be careful as we don't know the
> >extent of the code affected. In the meantime, we've also had ongoing
> >work for addressing the 2038 issue on 32-bit architectures.
> >
> >The second point is equally important. The benchmarks I've seen didn't
> >show a significant improvement and the messages I got on various
> >channels pretty much labeled ILP32 as a transitional stage to full LP64.
> >In this case, we need to balance the benefits of a close to native ABI
> >(future proof, slightly higher performance) vs. the cost of maintaining
> >such ABI in the kernel on the long term, especially if it's not widely
> >used/tested.
> 
> For us ILP32  is not about putting this into our product flier at all, it
> is about supporting real applications. We have an existing product line of
> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
> applications are currently in production. Our customers are looking to
> bring those applications (mostly in Networking and Telecom space) over to
> ARMv8. 
> 
> We think its an extremely risky strategy to say either future processors
> should incur the additional cost (power and complexity) of implementing
> Aarch32 instruction set or have no way of  supporting 32 bit applications
> at all.

Well, given that Cavium posted only 3 versions of this series since
September 2013, it doesn't seem critical at all.

> Apart from there being an installed base of 32 bit networking and telecom
> applications, we have also seen non-trivial performance gains with ILP32
> (for example, our SPECINT score goes up by 7% with ILP32 compared to
> LP64).

It would be good to re-run the benchmarks with the latest gcc since
LP64/AArch64 support has evolved in the meantime.

-- 
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 v5 00/23] ILP32 for ARM64

[Kapoor, Prasun]

On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:

>On Thu, Oct 01, 2015 at 09:49:46PM +, Pinski, Andrew wrote:
>> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
>> and redo the toolchain support for them.  Note this is going back to
>> the abi I had originally done when I submitted my original version
>> when it was asked to change time_t to be 64bit.
>
>One of the key aspects of kernel development is the ability to adapt
>quickly to new requests/insights. This implies releasing early and often
>rather than a new version roughly twice a year (IIRC, v1 was posted
>September 2013). Moreover, the success of the kernel is partly based on
>not getting stuck on old decisions (well, unless it breaks accepted user
>ABI).
>
>So, at the time, following x32 discussions, we thought of using the
>native ABI as much as possible. However, two important things happened
>since:
>
>1. libc community didn't like breaking the POSIX compliance
>2. No-one seems desperate for ILP32 on AArch64
>
>(1) is a fair point and I would rather be careful as we don't know the
>extent of the code affected. In the meantime, we've also had ongoing
>work for addressing the 2038 issue on 32-bit architectures.
>
>The second point is equally important. The benchmarks I've seen didn't
>show a significant improvement and the messages I got on various
>channels pretty much labeled ILP32 as a transitional stage to full LP64.
>In this case, we need to balance the benefits of a close to native ABI
>(future proof, slightly higher performance) vs. the cost of maintaining
>such ABI in the kernel on the long term, especially if it's not widely
>used/tested.


For us ILP32  is not about putting this into our product flier at all, it
is about supporting real applications. We have an existing product line of
MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
applications are currently in production. Our customers are looking to
bring those applications (mostly in Networking and Telecom space) over to
ARMv8. 

We think its an extremely risky strategy to say either future processors
should incur the additional cost (power and complexity) of implementing
Aarch32 instruction set or have no way of  supporting 32 bit applications
at all.

Apart from there being an installed base of 32 bit networking and telecom
applications, we have also seen non-trivial performance gains with ILP32
(for example, our SPECINT score goes up by 7% with ILP32 compared to
LP64).  



>
>We've seen the kernel patches and, following discussions on the lists,
>decided to change the original recommendation. IIRC, the main ideas (but
>you need to read various threads as I can't remember the details from
>6-7 months ago):
>
>a) separate syscall table for ILP32
>b) close to compat ABI with 32-bit time_t, off_t
>c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
>   would differ from compat, together with places where pointers are
>   passed)
>
>As I said previously, I'm not going to pay any attention to the patches
>in this series, it's nothing more than a rebase of a version I already
>reviewed.
>
>-- 
>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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Thu, Oct 01, 2015 at 09:49:46PM +, Pinski, Andrew wrote:
> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
> and redo the toolchain support for them.  Note this is going back to
> the abi I had originally done when I submitted my original version
> when it was asked to change time_t to be 64bit. 

One of the key aspects of kernel development is the ability to adapt
quickly to new requests/insights. This implies releasing early and often
rather than a new version roughly twice a year (IIRC, v1 was posted
September 2013). Moreover, the success of the kernel is partly based on
not getting stuck on old decisions (well, unless it breaks accepted user
ABI).

So, at the time, following x32 discussions, we thought of using the
native ABI as much as possible. However, two important things happened
since:

1. libc community didn't like breaking the POSIX compliance
2. No-one seems desperate for ILP32 on AArch64

(1) is a fair point and I would rather be careful as we don't know the
extent of the code affected. In the meantime, we've also had ongoing
work for addressing the 2038 issue on 32-bit architectures.

The second point is equally important. The benchmarks I've seen didn't
show a significant improvement and the messages I got on various
channels pretty much labeled ILP32 as a transitional stage to full LP64.
In this case, we need to balance the benefits of a close to native ABI
(future proof, slightly higher performance) vs. the cost of maintaining
such ABI in the kernel on the long term, especially if it's not widely
used/tested.

We've seen the kernel patches and, following discussions on the lists,
decided to change the original recommendation. IIRC, the main ideas (but
you need to read various threads as I can't remember the details from
6-7 months ago):

a) separate syscall table for ILP32
b) close to compat ABI with 32-bit time_t, off_t
c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
   would differ from compat, together with places where pointers are
   passed)

As I said previously, I'm not going to pay any attention to the patches
in this series, it's nothing more than a rebase of a version I already
reviewed.

-- 
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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Thu, Oct 01, 2015 at 09:49:46PM +, Pinski, Andrew wrote:
> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
> and redo the toolchain support for them.  Note this is going back to
> the abi I had originally done when I submitted my original version
> when it was asked to change time_t to be 64bit. 

One of the key aspects of kernel development is the ability to adapt
quickly to new requests/insights. This implies releasing early and often
rather than a new version roughly twice a year (IIRC, v1 was posted
September 2013). Moreover, the success of the kernel is partly based on
not getting stuck on old decisions (well, unless it breaks accepted user
ABI).

So, at the time, following x32 discussions, we thought of using the
native ABI as much as possible. However, two important things happened
since:

1. libc community didn't like breaking the POSIX compliance
2. No-one seems desperate for ILP32 on AArch64

(1) is a fair point and I would rather be careful as we don't know the
extent of the code affected. In the meantime, we've also had ongoing
work for addressing the 2038 issue on 32-bit architectures.

The second point is equally important. The benchmarks I've seen didn't
show a significant improvement and the messages I got on various
channels pretty much labeled ILP32 as a transitional stage to full LP64.
In this case, we need to balance the benefits of a close to native ABI
(future proof, slightly higher performance) vs. the cost of maintaining
such ABI in the kernel on the long term, especially if it's not widely
used/tested.

We've seen the kernel patches and, following discussions on the lists,
decided to change the original recommendation. IIRC, the main ideas (but
you need to read various threads as I can't remember the details from
6-7 months ago):

a) separate syscall table for ILP32
b) close to compat ABI with 32-bit time_t, off_t
c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
   would differ from compat, together with places where pointers are
   passed)

As I said previously, I'm not going to pay any attention to the patches
in this series, it's nothing more than a rebase of a version I already
reviewed.

-- 
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 v5 00/23] ILP32 for ARM64

[Kapoor, Prasun]

On 10/2/15, 2:37 AM, "Catalin Marinas"  wrote:

>On Thu, Oct 01, 2015 at 09:49:46PM +, Pinski, Andrew wrote:
>> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
>> and redo the toolchain support for them.  Note this is going back to
>> the abi I had originally done when I submitted my original version
>> when it was asked to change time_t to be 64bit.
>
>One of the key aspects of kernel development is the ability to adapt
>quickly to new requests/insights. This implies releasing early and often
>rather than a new version roughly twice a year (IIRC, v1 was posted
>September 2013). Moreover, the success of the kernel is partly based on
>not getting stuck on old decisions (well, unless it breaks accepted user
>ABI).
>
>So, at the time, following x32 discussions, we thought of using the
>native ABI as much as possible. However, two important things happened
>since:
>
>1. libc community didn't like breaking the POSIX compliance
>2. No-one seems desperate for ILP32 on AArch64
>
>(1) is a fair point and I would rather be careful as we don't know the
>extent of the code affected. In the meantime, we've also had ongoing
>work for addressing the 2038 issue on 32-bit architectures.
>
>The second point is equally important. The benchmarks I've seen didn't
>show a significant improvement and the messages I got on various
>channels pretty much labeled ILP32 as a transitional stage to full LP64.
>In this case, we need to balance the benefits of a close to native ABI
>(future proof, slightly higher performance) vs. the cost of maintaining
>such ABI in the kernel on the long term, especially if it's not widely
>used/tested.


For us ILP32  is not about putting this into our product flier at all, it
is about supporting real applications. We have an existing product line of
MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
applications are currently in production. Our customers are looking to
bring those applications (mostly in Networking and Telecom space) over to
ARMv8. 

We think its an extremely risky strategy to say either future processors
should incur the additional cost (power and complexity) of implementing
Aarch32 instruction set or have no way of  supporting 32 bit applications
at all.

Apart from there being an installed base of 32 bit networking and telecom
applications, we have also seen non-trivial performance gains with ILP32
(for example, our SPECINT score goes up by 7% with ILP32 compared to
LP64).  



>
>We've seen the kernel patches and, following discussions on the lists,
>decided to change the original recommendation. IIRC, the main ideas (but
>you need to read various threads as I can't remember the details from
>6-7 months ago):
>
>a) separate syscall table for ILP32
>b) close to compat ABI with 32-bit time_t, off_t
>c) asm-generic/unistd.h rather than asm/unistd32.h (that's where it
>   would differ from compat, together with places where pointers are
>   passed)
>
>As I said previously, I'm not going to pay any attention to the patches
>in this series, it's nothing more than a rebase of a version I already
>reviewed.
>
>-- 
>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 v5 00/23] ILP32 for ARM64

[Pinski, Andrew]

> On Oct 1, 2015, at 2:29 PM, Arnd Bergmann  wrote:
> 
>> On Thursday 01 October 2015 22:15:20 Yury Norov wrote:
>> 
>> Regarding time_t, it, of course, doesn't takes much time to make it
>> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
>> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
> 
> I'm pretty sure that n32 has 32-bit time_t, and we know that it still
> causes real-world problems on x32: socket timestamps, v4l, alsa and
> other subsystems all have bugs in this area that are hard to fix.
> 
>> That's OK for BSD as well. The objection may come from users of ABI,
>> complaining portability problems, but I found no such complains in
>> public discussions.
>> 
>> Nevertheless, as I told, I do not see any problem to rework time_t.
>> But some arguments supporting this decision are appreciated.
>> 
>> The downside of 32 bit time_t is that we still face Y2038 problem,
>> but that's the other story fixing it.
> 
> The main reason for 32-bit time_t is compatibility with existing
> ioctls (also getsockopts and some others), and having a sane way
> for fixing them. We cannot change compat_time_t to be 64-bit
> without breaking arm32 compat mode, and we can't use the native
> 64-bit ioctl implementation on ARM64/ILP32 because that breaks
> all interfaces that pass 'long' or a pointer.
> 
> This means drivers that currently pass a time_t (or timeval, timespec
> etc) need to not only have a compat_ioctl handler to convert it,
> they also need to check whether which of the two compat modes they
> are talking to. This is a mess to add (I know, because I'm working
> on this for y2038 compliance for normal 32-bit mode), and making
> the two behave differently makes it even harder to get right for
> all cases.
> 
>> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
>> may suffer, but, again, there're no complains, and in long run it
>> looks better.
> 
> __kernel_long_t isn't actually used that much, and rarely used in
> places where it matters. The idea was to be able to reuse the
> native syscalls rather than the compat syscall calls, but that
> comes with the downside of defining the ABI in a way that is
> incompatible with all other 32-bit user space.
> 
> Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
> a good idea in principle, but it breaks device drivers that
> expect user space to pass 32-bit arguments. For any interface
> that really needs 64-bit data, we have to fix it for all
> 32-bit architectures, and we're better off avoiding special
> cases.

Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and redo 
the toolchain support for them.  Note this is going back to the abi I had 
originally done when I submitted my original version when it was asked to 
change time_t to be 64bit. 

Thanks,
Andrew


> 
>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 v5 00/23] ILP32 for ARM64

[Arnd Bergmann]

On Thursday 01 October 2015 22:15:20 Yury Norov wrote:

> Regarding time_t, it, of course, doesn't takes much time to make it
> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.

I'm pretty sure that n32 has 32-bit time_t, and we know that it still
causes real-world problems on x32: socket timestamps, v4l, alsa and
other subsystems all have bugs in this area that are hard to fix.

> That's OK for BSD as well. The objection may come from users of ABI,
> complaining portability problems, but I found no such complains in
> public discussions.
>
> Nevertheless, as I told, I do not see any problem to rework time_t.
> But some arguments supporting this decision are appreciated.
> 
> The downside of 32 bit time_t is that we still face Y2038 problem,
> but that's the other story fixing it.

The main reason for 32-bit time_t is compatibility with existing
ioctls (also getsockopts and some others), and having a sane way
for fixing them. We cannot change compat_time_t to be 64-bit
without breaking arm32 compat mode, and we can't use the native
64-bit ioctl implementation on ARM64/ILP32 because that breaks
all interfaces that pass 'long' or a pointer.

This means drivers that currently pass a time_t (or timeval, timespec
etc) need to not only have a compat_ioctl handler to convert it,
they also need to check whether which of the two compat modes they
are talking to. This is a mess to add (I know, because I'm working
on this for y2038 compliance for normal 32-bit mode), and making
the two behave differently makes it even harder to get right for
all cases.

> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
> may suffer, but, again, there're no complains, and in long run it
> looks better.

__kernel_long_t isn't actually used that much, and rarely used in
places where it matters. The idea was to be able to reuse the
native syscalls rather than the compat syscall calls, but that
comes with the downside of defining the ABI in a way that is
incompatible with all other 32-bit user space.

Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
a good idea in principle, but it breaks device drivers that
expect user space to pass 32-bit arguments. For any interface
that really needs 64-bit data, we have to fix it for all
32-bit architectures, and we're better off avoiding special
cases.

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 v5 00/23] ILP32 for ARM64

[Yury Norov]

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > >   See https://lkml.org/lkml/2015/4/13/814
> > >   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > >   Briefly,
> > >- for compatibility;
> > >- for performance;
> > >- for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

Hi, Mark,

>From you, I got more on what happens with ILP32 than from my company.
Thank you. I know people participated Linaro Connect, and will ask
them for details. And, if possible, will share it here.

BR,
Yury.
--
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 v5 00/23] ILP32 for ARM64

[Yury Norov]

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> > V5 reincarnation for ILP32.
> > 
> > This is mostly the same code as Andrew suggested in v3:
> > https://lkml.org/lkml/2014/9/3/704.
> > 
> > V4 series and discussion:
> > https://lkml.org/lkml/2015/4/13/691
> > 
> > Discussion on v3 and v4 raised questions and some disagreement in community,
> > and therefore patches are not accepted till now. In this v5 I tried to 
> > avoid any
> > changes that are not about obvious fixes, so all interface and 
> > implementation
> > questions are still here.
> 
> This thing comes roughly every 5-6 months, so I don't think it's worth
> reviewing it again and forgetting about it until sometime next year. We
> also had discussions on the v4 and IIRC we agreed that the ABI should be
> closer to AArch32/compat in terms of __kernel_size_t, time_t but with
> the canonical set of system calls from the asm-generic/unistd.h.
> 
> > In v5:
> >  - rebased on top of 4.3.0-rc3;
> >  - build fixed if ILP32 enabled without AARCH32;
> >  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
> >debug tools like gdb and strace;
> >  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
> >dropped as breaking tests;
> >  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
> >handling of msgrcv, msgsnd;
> >  - other minor fixes.
> 
> So apart from rebasing, there are no ABI changes. I don't think it's
> worth re-discussing the points raised during v4.
> 
> > Questions under discussion:
> >  - What for ILP32 on ARM64?
> > See https://lkml.org/lkml/2015/4/13/814
> > and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > Briefly,
> >  - for compatibility;
> >  - for performance;
> >  - for memory saving.
> 
> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 

Adding Prasun Capoor 

I'm not familar with details. I know that ARM32 compatibility is the main
concern now. I think, in long run compatibility doesn't mean much.
The performance does instead. Bamvor Jian Zhang reports 10%
performance gain, and I think noone will miss the chance to became 10%
faster, if speed is a real concern, just after rebuilding the application.

> That said, I'm fine with agreeing on an ABI and see whether it takes off
> before any merging decisions.
> 
> >  - ABI questions: time_t and so on;
> > I think we are out of choice now. Patches to GCC and Glibc are
> > upstreamed more than a year ago, and there already might be a code 
> > compiled
> > against existing ABI. At the end, there is no major disagreement, and 
> > final
> > word is after ABI users. And I found no objections from that side.
> 
> CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
> AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
> merged because we did not reach an agreement on the kernel ABI (it would
> be rather silly to push something into mainline glibc that's not
> officially supported by Linux).
> 
> I really don't care if there is compiled code out there using out of
> tree patches for glibc and the kernel.

You right, they are out of tree. Sorry.

> 
> >  - Implementation questions: use ILP32 separated table or not, and others;
> > Code proposed by Andrew works just fine for more than a year,
> > and it even shows slightly better performance comparing to LP64:
> > http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > So I see no reason to change something except obvious bugs, if found.
> 
> As I said, with patches twice a year, I don't remember the past
> discussions. So normally you should start with v4 and address the
> comments there. But you seem to have refreshed v3.
> 
> Anyway, if by table you mean the syscall table, I think on v4 we agreed
> on a separate ILP32 syscall table using the generic syscall numbering
> but with some compat syscall pointers where applicable.
> 

We already have separated ILP32 syscall table, see patch 19 in this
patchset. This is in fact the option e), suggested by Arnd as best
option for him. https://lkml.org/lkml/2015/4/17/237

Regarding time_t, it, of course, doesn't takes much time to make it
32-bit, but I think 64 bit is better because of Y2038. X32 and mips
n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
That's OK for BSD as well. The objection may come from users of ABI,
complaining portability problems, but I found no such complains in
public discussions.

Nevertheless, as I told, I do not see any problem to rework time_t.
But some arguments supporting 

Re: [PATCH v5 00/23] ILP32 for ARM64

[Andrey Konovalov]

On 10/01/2015 02:36 PM, Mark Brown wrote:

On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:



Indeed.  On that subject there was some discussion at Linaro Connect
last week about work (being done outside Linaro, not sure how public it
is at this point) to pull together the current state of the art into a
Docker container image which people can use for benchmarking and as a
reference for how to pull things together.  That should help with the
analysis, it'll at least make it easier for other people to reproduce
any benchmarking results.


Using Docker image sounds like a great idea.


That's fine and I would welcome it. However, I'm definitely against
using non-agreed ABI and further spreading such toolchains (or kernel


You might want to speak to some of your colleagues about that...  in any
case I'll reply off list later today with information on the third party
working on this so you can get in touch, like I say I'm not sure how
public that work is at this point.


patches; Linaro's tracking kernel has kept these patches for a long
time, even though the ABI has been NAK'ed).


I know, I'm not thrilled about that either.  :/


Same for me.
As you have noticed, ILP32 was removed from Linaro's tracking kernel recently.
The thing is that we (builds team in Linaro) have been requested
to have a CI loop for ILP32. So I'll continue running it, but will use a
separate git branch for ILP32. The linux-linaro branch will not have ILP32
any more (or at least until ILP32 ABI is agreed on).

Thanks,
Andrey



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
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 v5 00/23] ILP32 for ARM64

[Mark Brown]

On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:

> > Indeed.  On that subject there was some discussion at Linaro Connect
> > last week about work (being done outside Linaro, not sure how public it
> > is at this point) to pull together the current state of the art into a
> > Docker container image which people can use for benchmarking and as a
> > reference for how to pull things together.  That should help with the
> > analysis, it'll at least make it easier for other people to reproduce
> > any benchmarking results.

> That's fine and I would welcome it. However, I'm definitely against
> using non-agreed ABI and further spreading such toolchains (or kernel

You might want to speak to some of your colleagues about that...  in any
case I'll reply off list later today with information on the third party
working on this so you can get in touch, like I say I'm not sure how
public that work is at this point.

> patches; Linaro's tracking kernel has kept these patches for a long
> time, even though the ABI has been NAK'ed).

I know, I'm not thrilled about that either.  :/


signature.asc
Description: Digital signature

Re: [PATCH v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > >   See https://lkml.org/lkml/2015/4/13/814
> > >   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > >   Briefly,
> > >- for compatibility;
> > >- for performance;
> > >- for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

That's fine and I would welcome it. However, I'm definitely against
using non-agreed ABI and further spreading such toolchains (or kernel
patches; Linaro's tracking kernel has kept these patches for a long
time, even though the ABI has been NAK'ed).

-- 
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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > >   See https://lkml.org/lkml/2015/4/13/814
> > >   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > >   Briefly,
> > >- for compatibility;
> > >- for performance;
> > >- for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

That's fine and I would welcome it. However, I'm definitely against
using non-agreed ABI and further spreading such toolchains (or kernel
patches; Linaro's tracking kernel has kept these patches for a long
time, even though the ABI has been NAK'ed).

-- 
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 v5 00/23] ILP32 for ARM64

[Mark Brown]

On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:

> > Indeed.  On that subject there was some discussion at Linaro Connect
> > last week about work (being done outside Linaro, not sure how public it
> > is at this point) to pull together the current state of the art into a
> > Docker container image which people can use for benchmarking and as a
> > reference for how to pull things together.  That should help with the
> > analysis, it'll at least make it easier for other people to reproduce
> > any benchmarking results.

> That's fine and I would welcome it. However, I'm definitely against
> using non-agreed ABI and further spreading such toolchains (or kernel

You might want to speak to some of your colleagues about that...  in any
case I'll reply off list later today with information on the third party
working on this so you can get in touch, like I say I'm not sure how
public that work is at this point.

> patches; Linaro's tracking kernel has kept these patches for a long
> time, even though the ABI has been NAK'ed).

I know, I'm not thrilled about that either.  :/


signature.asc
Description: Digital signature

Re: [PATCH v5 00/23] ILP32 for ARM64

[Andrey Konovalov]

On 10/01/2015 02:36 PM, Mark Brown wrote:

On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote:

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:



Indeed.  On that subject there was some discussion at Linaro Connect
last week about work (being done outside Linaro, not sure how public it
is at this point) to pull together the current state of the art into a
Docker container image which people can use for benchmarking and as a
reference for how to pull things together.  That should help with the
analysis, it'll at least make it easier for other people to reproduce
any benchmarking results.


Using Docker image sounds like a great idea.


That's fine and I would welcome it. However, I'm definitely against
using non-agreed ABI and further spreading such toolchains (or kernel


You might want to speak to some of your colleagues about that...  in any
case I'll reply off list later today with information on the third party
working on this so you can get in touch, like I say I'm not sure how
public that work is at this point.


patches; Linaro's tracking kernel has kept these patches for a long
time, even though the ABI has been NAK'ed).


I know, I'm not thrilled about that either.  :/


Same for me.
As you have noticed, ILP32 was removed from Linaro's tracking kernel recently.
The thing is that we (builds team in Linaro) have been requested
to have a CI loop for ILP32. So I'll continue running it, but will use a
separate git branch for ILP32. The linux-linaro branch will not have ILP32
any more (or at least until ILP32 ABI is agreed on).

Thanks,
Andrey



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
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 v5 00/23] ILP32 for ARM64

[Yury Norov]

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> > V5 reincarnation for ILP32.
> > 
> > This is mostly the same code as Andrew suggested in v3:
> > https://lkml.org/lkml/2014/9/3/704.
> > 
> > V4 series and discussion:
> > https://lkml.org/lkml/2015/4/13/691
> > 
> > Discussion on v3 and v4 raised questions and some disagreement in community,
> > and therefore patches are not accepted till now. In this v5 I tried to 
> > avoid any
> > changes that are not about obvious fixes, so all interface and 
> > implementation
> > questions are still here.
> 
> This thing comes roughly every 5-6 months, so I don't think it's worth
> reviewing it again and forgetting about it until sometime next year. We
> also had discussions on the v4 and IIRC we agreed that the ABI should be
> closer to AArch32/compat in terms of __kernel_size_t, time_t but with
> the canonical set of system calls from the asm-generic/unistd.h.
> 
> > In v5:
> >  - rebased on top of 4.3.0-rc3;
> >  - build fixed if ILP32 enabled without AARCH32;
> >  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
> >debug tools like gdb and strace;
> >  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
> >dropped as breaking tests;
> >  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
> >handling of msgrcv, msgsnd;
> >  - other minor fixes.
> 
> So apart from rebasing, there are no ABI changes. I don't think it's
> worth re-discussing the points raised during v4.
> 
> > Questions under discussion:
> >  - What for ILP32 on ARM64?
> > See https://lkml.org/lkml/2015/4/13/814
> > and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > Briefly,
> >  - for compatibility;
> >  - for performance;
> >  - for memory saving.
> 
> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 

Adding Prasun Capoor 

I'm not familar with details. I know that ARM32 compatibility is the main
concern now. I think, in long run compatibility doesn't mean much.
The performance does instead. Bamvor Jian Zhang reports 10%
performance gain, and I think noone will miss the chance to became 10%
faster, if speed is a real concern, just after rebuilding the application.

> That said, I'm fine with agreeing on an ABI and see whether it takes off
> before any merging decisions.
> 
> >  - ABI questions: time_t and so on;
> > I think we are out of choice now. Patches to GCC and Glibc are
> > upstreamed more than a year ago, and there already might be a code 
> > compiled
> > against existing ABI. At the end, there is no major disagreement, and 
> > final
> > word is after ABI users. And I found no objections from that side.
> 
> CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
> AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
> merged because we did not reach an agreement on the kernel ABI (it would
> be rather silly to push something into mainline glibc that's not
> officially supported by Linux).
> 
> I really don't care if there is compiled code out there using out of
> tree patches for glibc and the kernel.

You right, they are out of tree. Sorry.

> 
> >  - Implementation questions: use ILP32 separated table or not, and others;
> > Code proposed by Andrew works just fine for more than a year,
> > and it even shows slightly better performance comparing to LP64:
> > http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > So I see no reason to change something except obvious bugs, if found.
> 
> As I said, with patches twice a year, I don't remember the past
> discussions. So normally you should start with v4 and address the
> comments there. But you seem to have refreshed v3.
> 
> Anyway, if by table you mean the syscall table, I think on v4 we agreed
> on a separate ILP32 syscall table using the generic syscall numbering
> but with some compat syscall pointers where applicable.
> 

We already have separated ILP32 syscall table, see patch 19 in this
patchset. This is in fact the option e), suggested by Arnd as best
option for him. https://lkml.org/lkml/2015/4/17/237

Regarding time_t, it, of course, doesn't takes much time to make it
32-bit, but I think 64 bit is better because of Y2038. X32 and mips
n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
That's OK for BSD as well. The objection may come from users of ABI,
complaining portability problems, but I found no such complains in
public discussions.

Nevertheless, as I told, I do not see any problem to rework time_t.

Re: [PATCH v5 00/23] ILP32 for ARM64

[Yury Norov]

On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> 
> > >  - What for ILP32 on ARM64?
> > >   See https://lkml.org/lkml/2015/4/13/814
> > >   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > >   Briefly,
> > >- for compatibility;
> > >- for performance;
> > >- for memory saving.
> 
> > Does anyone actually need this ABI? And by "need" I don't mean a
> > tick-box on product fliers but actually someone going to use it on real
> > systems in the field. Because I'm not keen on maintaining an ABI in the
> > kernel just as a PR exercise. I have yet to see conclusive benchmarks
> > that ILP32 is a real win vs LP64 but happy to be proven wrong.
> 
> Indeed.  On that subject there was some discussion at Linaro Connect
> last week about work (being done outside Linaro, not sure how public it
> is at this point) to pull together the current state of the art into a
> Docker container image which people can use for benchmarking and as a
> reference for how to pull things together.  That should help with the
> analysis, it'll at least make it easier for other people to reproduce
> any benchmarking results.

Hi, Mark,

>From you, I got more on what happens with ILP32 than from my company.
Thank you. I know people participated Linaro Connect, and will ask
them for details. And, if possible, will share it here.

BR,
Yury.
--
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 v5 00/23] ILP32 for ARM64

[Pinski, Andrew]

> On Oct 1, 2015, at 2:29 PM, Arnd Bergmann  wrote:
> 
>> On Thursday 01 October 2015 22:15:20 Yury Norov wrote:
>> 
>> Regarding time_t, it, of course, doesn't takes much time to make it
>> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
>> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.
> 
> I'm pretty sure that n32 has 32-bit time_t, and we know that it still
> causes real-world problems on x32: socket timestamps, v4l, alsa and
> other subsystems all have bugs in this area that are hard to fix.
> 
>> That's OK for BSD as well. The objection may come from users of ABI,
>> complaining portability problems, but I found no such complains in
>> public discussions.
>> 
>> Nevertheless, as I told, I do not see any problem to rework time_t.
>> But some arguments supporting this decision are appreciated.
>> 
>> The downside of 32 bit time_t is that we still face Y2038 problem,
>> but that's the other story fixing it.
> 
> The main reason for 32-bit time_t is compatibility with existing
> ioctls (also getsockopts and some others), and having a sane way
> for fixing them. We cannot change compat_time_t to be 64-bit
> without breaking arm32 compat mode, and we can't use the native
> 64-bit ioctl implementation on ARM64/ILP32 because that breaks
> all interfaces that pass 'long' or a pointer.
> 
> This means drivers that currently pass a time_t (or timeval, timespec
> etc) need to not only have a compat_ioctl handler to convert it,
> they also need to check whether which of the two compat modes they
> are talking to. This is a mess to add (I know, because I'm working
> on this for y2038 compliance for normal 32-bit mode), and making
> the two behave differently makes it even harder to get right for
> all cases.
> 
>> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
>> may suffer, but, again, there're no complains, and in long run it
>> looks better.
> 
> __kernel_long_t isn't actually used that much, and rarely used in
> places where it matters. The idea was to be able to reuse the
> native syscalls rather than the compat syscall calls, but that
> comes with the downside of defining the ABI in a way that is
> incompatible with all other 32-bit user space.
> 
> Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
> a good idea in principle, but it breaks device drivers that
> expect user space to pass 32-bit arguments. For any interface
> that really needs 64-bit data, we have to fix it for all
> 32-bit architectures, and we're better off avoiding special
> cases.

Ok, we will rewrite these patches using 32bit time_t and 32bit off_t and redo 
the toolchain support for them.  Note this is going back to the abi I had 
originally done when I submitted my original version when it was asked to 
change time_t to be 64bit. 

Thanks,
Andrew


> 
>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 v5 00/23] ILP32 for ARM64

[Arnd Bergmann]

On Thursday 01 October 2015 22:15:20 Yury Norov wrote:

> Regarding time_t, it, of course, doesn't takes much time to make it
> 32-bit, but I think 64 bit is better because of Y2038. X32 and mips
> n32 has time_t 64-bit (and ppc, not sure), and that's OK for them.

I'm pretty sure that n32 has 32-bit time_t, and we know that it still
causes real-world problems on x32: socket timestamps, v4l, alsa and
other subsystems all have bugs in this area that are hard to fix.

> That's OK for BSD as well. The objection may come from users of ABI,
> complaining portability problems, but I found no such complains in
> public discussions.
>
> Nevertheless, as I told, I do not see any problem to rework time_t.
> But some arguments supporting this decision are appreciated.
> 
> The downside of 32 bit time_t is that we still face Y2038 problem,
> but that's the other story fixing it.

The main reason for 32-bit time_t is compatibility with existing
ioctls (also getsockopts and some others), and having a sane way
for fixing them. We cannot change compat_time_t to be 64-bit
without breaking arm32 compat mode, and we can't use the native
64-bit ioctl implementation on ARM64/ILP32 because that breaks
all interfaces that pass 'long' or a pointer.

This means drivers that currently pass a time_t (or timeval, timespec
etc) need to not only have a compat_ioctl handler to convert it,
they also need to check whether which of the two compat modes they
are talking to. This is a mess to add (I know, because I'm working
on this for y2038 compliance for normal 32-bit mode), and making
the two behave differently makes it even harder to get right for
all cases.

> __kernel_long_t is the same. Now it's 64 bits length. Compatibility
> may suffer, but, again, there're no complains, and in long run it
> looks better.

__kernel_long_t isn't actually used that much, and rarely used in
places where it matters. The idea was to be able to reuse the
native syscalls rather than the compat syscall calls, but that
comes with the downside of defining the ABI in a way that is
incompatible with all other 32-bit user space.

Having a 64-bit __kernel_off_t is similar to the 64-bit time_t:
a good idea in principle, but it breaks device drivers that
expect user space to pass 32-bit arguments. For any interface
that really needs 64-bit data, we have to fix it for all
32-bit architectures, and we're better off avoiding special
cases.

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 v5 00/23] ILP32 for ARM64

[Mark Brown]

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:

> >  - What for ILP32 on ARM64?
> > See https://lkml.org/lkml/2015/4/13/814
> > and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > Briefly,
> >  - for compatibility;
> >  - for performance;
> >  - for memory saving.

> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.

Indeed.  On that subject there was some discussion at Linaro Connect
last week about work (being done outside Linaro, not sure how public it
is at this point) to pull together the current state of the art into a
Docker container image which people can use for benchmarking and as a
reference for how to pull things together.  That should help with the
analysis, it'll at least make it easier for other people to reproduce
any benchmarking results.


signature.asc
Description: Digital signature

Re: [PATCH v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> V5 reincarnation for ILP32.
> 
> This is mostly the same code as Andrew suggested in v3:
>   https://lkml.org/lkml/2014/9/3/704.
> 
> V4 series and discussion:
>   https://lkml.org/lkml/2015/4/13/691
> 
> Discussion on v3 and v4 raised questions and some disagreement in community,
> and therefore patches are not accepted till now. In this v5 I tried to avoid 
> any
> changes that are not about obvious fixes, so all interface and implementation
> questions are still here.

This thing comes roughly every 5-6 months, so I don't think it's worth
reviewing it again and forgetting about it until sometime next year. We
also had discussions on the v4 and IIRC we agreed that the ABI should be
closer to AArch32/compat in terms of __kernel_size_t, time_t but with
the canonical set of system calls from the asm-generic/unistd.h.

> In v5:
>  - rebased on top of 4.3.0-rc3;
>  - build fixed if ILP32 enabled without AARCH32;
>  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
>debug tools like gdb and strace;
>  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
>dropped as breaking tests;
>  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
>handling of msgrcv, msgsnd;
>  - other minor fixes.

So apart from rebasing, there are no ABI changes. I don't think it's
worth re-discussing the points raised during v4.

> Questions under discussion:
>  - What for ILP32 on ARM64?
>   See https://lkml.org/lkml/2015/4/13/814
>   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
>   Briefly,
>- for compatibility;
>- for performance;
>- for memory saving.

Does anyone actually need this ABI? And by "need" I don't mean a
tick-box on product fliers but actually someone going to use it on real
systems in the field. Because I'm not keen on maintaining an ABI in the
kernel just as a PR exercise. I have yet to see conclusive benchmarks
that ILP32 is a real win vs LP64 but happy to be proven wrong.

That said, I'm fine with agreeing on an ABI and see whether it takes off
before any merging decisions.

>  - ABI questions: time_t and so on;
>   I think we are out of choice now. Patches to GCC and Glibc are
>   upstreamed more than a year ago, and there already might be a code 
> compiled
>   against existing ABI. At the end, there is no major disagreement, and 
> final
>   word is after ABI users. And I found no objections from that side.

CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
merged because we did not reach an agreement on the kernel ABI (it would
be rather silly to push something into mainline glibc that's not
officially supported by Linux).

I really don't care if there is compiled code out there using out of
tree patches for glibc and the kernel.

>  - Implementation questions: use ILP32 separated table or not, and others;
>   Code proposed by Andrew works just fine for more than a year,
>   and it even shows slightly better performance comparing to LP64:
>   http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
>   So I see no reason to change something except obvious bugs, if found.

As I said, with patches twice a year, I don't remember the past
discussions. So normally you should start with v4 and address the
comments there. But you seem to have refreshed v3.

Anyway, if by table you mean the syscall table, I think on v4 we agreed
on a separate ILP32 syscall table using the generic syscall numbering
but with some compat syscall pointers where applicable.

-- 
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 v5 00/23] ILP32 for ARM64

[Catalin Marinas]

On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
> V5 reincarnation for ILP32.
> 
> This is mostly the same code as Andrew suggested in v3:
>   https://lkml.org/lkml/2014/9/3/704.
> 
> V4 series and discussion:
>   https://lkml.org/lkml/2015/4/13/691
> 
> Discussion on v3 and v4 raised questions and some disagreement in community,
> and therefore patches are not accepted till now. In this v5 I tried to avoid 
> any
> changes that are not about obvious fixes, so all interface and implementation
> questions are still here.

This thing comes roughly every 5-6 months, so I don't think it's worth
reviewing it again and forgetting about it until sometime next year. We
also had discussions on the v4 and IIRC we agreed that the ABI should be
closer to AArch32/compat in terms of __kernel_size_t, time_t but with
the canonical set of system calls from the asm-generic/unistd.h.

> In v5:
>  - rebased on top of 4.3.0-rc3;
>  - build fixed if ILP32 enabled without AARCH32;
>  - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
>debug tools like gdb and strace;
>  - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
>dropped as breaking tests;
>  - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
>handling of msgrcv, msgsnd;
>  - other minor fixes.

So apart from rebasing, there are no ABI changes. I don't think it's
worth re-discussing the points raised during v4.

> Questions under discussion:
>  - What for ILP32 on ARM64?
>   See https://lkml.org/lkml/2015/4/13/814
>   and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
>   Briefly,
>- for compatibility;
>- for performance;
>- for memory saving.

Does anyone actually need this ABI? And by "need" I don't mean a
tick-box on product fliers but actually someone going to use it on real
systems in the field. Because I'm not keen on maintaining an ABI in the
kernel just as a PR exercise. I have yet to see conclusive benchmarks
that ILP32 is a real win vs LP64 but happy to be proven wrong.

That said, I'm fine with agreeing on an ABI and see whether it takes off
before any merging decisions.

>  - ABI questions: time_t and so on;
>   I think we are out of choice now. Patches to GCC and Glibc are
>   upstreamed more than a year ago, and there already might be a code 
> compiled
>   against existing ABI. At the end, there is no major disagreement, and 
> final
>   word is after ABI users. And I found no objections from that side.

CORRECTION: patches for gcc have been upstreamed, that's the ELF and PCS
AArch64 ILP32 ABI. The syscall ABI which goes in glibc hasn't been
merged because we did not reach an agreement on the kernel ABI (it would
be rather silly to push something into mainline glibc that's not
officially supported by Linux).

I really don't care if there is compiled code out there using out of
tree patches for glibc and the kernel.

>  - Implementation questions: use ILP32 separated table or not, and others;
>   Code proposed by Andrew works just fine for more than a year,
>   and it even shows slightly better performance comparing to LP64:
>   http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
>   So I see no reason to change something except obvious bugs, if found.

As I said, with patches twice a year, I don't remember the past
discussions. So normally you should start with v4 and address the
comments there. But you seem to have refreshed v3.

Anyway, if by table you mean the syscall table, I think on v4 we agreed
on a separate ILP32 syscall table using the generic syscall numbering
but with some compat syscall pointers where applicable.

-- 
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 v5 00/23] ILP32 for ARM64

[Mark Brown]

On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:

> >  - What for ILP32 on ARM64?
> > See https://lkml.org/lkml/2015/4/13/814
> > and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
> > Briefly,
> >  - for compatibility;
> >  - for performance;
> >  - for memory saving.

> Does anyone actually need this ABI? And by "need" I don't mean a
> tick-box on product fliers but actually someone going to use it on real
> systems in the field. Because I'm not keen on maintaining an ABI in the
> kernel just as a PR exercise. I have yet to see conclusive benchmarks
> that ILP32 is a real win vs LP64 but happy to be proven wrong.

Indeed.  On that subject there was some discussion at Linaro Connect
last week about work (being done outside Linaro, not sure how public it
is at this point) to pull together the current state of the art into a
Docker container image which people can use for benchmarking and as a
reference for how to pull things together.  That should help with the
analysis, it'll at least make it easier for other people to reproduce
any benchmarking results.


signature.asc
Description: Digital signature

[PATCH v5 00/23] ILP32 for ARM64

[Yury Norov]

V5 reincarnation for ILP32.

This is mostly the same code as Andrew suggested in v3:
https://lkml.org/lkml/2014/9/3/704.

V4 series and discussion:
https://lkml.org/lkml/2015/4/13/691

Discussion on v3 and v4 raised questions and some disagreement in community,
and therefore patches are not accepted till now. In this v5 I tried to avoid any
changes that are not about obvious fixes, so all interface and implementation
questions are still here.

In v5:
 - rebased on top of 4.3.0-rc3;
 - build fixed if ILP32 enabled without AARCH32;
 - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
   debug tools like gdb and strace;
 - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
   dropped as breaking tests;
 - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
   handling of msgrcv, msgsnd;
 - other minor fixes.

Questions under discussion:
 - What for ILP32 on ARM64?
See https://lkml.org/lkml/2015/4/13/814
and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
Briefly,
 - for compatibility;
 - for performance;
 - for memory saving.

 - ABI questions: time_t and so on;
I think we are out of choice now. Patches to GCC and Glibc are
upstreamed more than a year ago, and there already might be a code 
compiled
against existing ABI. At the end, there is no major disagreement, and 
final
word is after ABI users. And I found no objections from that side.

 - Implementation questions: use ILP32 separated table or not, and others;
Code proposed by Andrew works just fine for more than a year,
and it even shows slightly better performance comparing to LP64:
http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
So I see no reason to change something except obvious bugs, if found.

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 (4):
  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: change COMPAT_ELF_PLATFORM to report a a subplatform for
ILP32

Yury Norov (1):
  aarch64: ilp32: msgrcv, msgsnd handlers

 Documentation/arm64/ilp32.txt  |  64 ++
 arch/arm64/Kconfig |  14 +-
 arch/arm64/Makefile|   6 +-
 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 |  12 +-
 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|   8 +-
 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|   4 +-
 

[PATCH v5 00/23] ILP32 for ARM64

[Yury Norov]

V5 reincarnation for ILP32.

This is mostly the same code as Andrew suggested in v3:
https://lkml.org/lkml/2014/9/3/704.

V4 series and discussion:
https://lkml.org/lkml/2015/4/13/691

Discussion on v3 and v4 raised questions and some disagreement in community,
and therefore patches are not accepted till now. In this v5 I tried to avoid any
changes that are not about obvious fixes, so all interface and implementation
questions are still here.

In v5:
 - rebased on top of 4.3.0-rc3;
 - build fixed if ILP32 enabled without AARCH32;
 - PATCH v4 22/24 (use compat for stack_t) dropped because it confuses
   debug tools like gdb and strace;
 - PATCH v4 20/24 (use compat-syscalls for msgsnd and msgrcv for ILP32)
   dropped as breaking tests;
 - PATCH v5 22/23 (msgrcv, msgsnd handlers) introduced for proper 
   handling of msgrcv, msgsnd;
 - other minor fixes.

Questions under discussion:
 - What for ILP32 on ARM64?
See https://lkml.org/lkml/2015/4/13/814
and http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
Briefly,
 - for compatibility;
 - for performance;
 - for memory saving.

 - ABI questions: time_t and so on;
I think we are out of choice now. Patches to GCC and Glibc are
upstreamed more than a year ago, and there already might be a code 
compiled
against existing ABI. At the end, there is no major disagreement, and 
final
word is after ABI users. And I found no objections from that side.

 - Implementation questions: use ILP32 separated table or not, and others;
Code proposed by Andrew works just fine for more than a year,
and it even shows slightly better performance comparing to LP64:
http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/121100
So I see no reason to change something except obvious bugs, if found.

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 (4):
  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: change COMPAT_ELF_PLATFORM to report a a subplatform for
ILP32

Yury Norov (1):
  aarch64: ilp32: msgrcv, msgsnd handlers

 Documentation/arm64/ilp32.txt  |  64 ++
 arch/arm64/Kconfig |  14 +-
 arch/arm64/Makefile|   6 +-
 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 |  12 +-
 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|   8 +-
 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|   4 +-