Re: Ping: ILP32 on aarch64 patches

[Andrew Pinski <pinskia at gmail dot com>]

On Sun, Jan 1, 2017 at 2:20 PM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> Hi, Szabolcs
>
> [Add Arnd, Catalin, Maxim, Bamvor and Andrew]
>
> On Wed, Dec 28, 2016 at 11:07:53PM +0100, Szabolcs Nagy wrote:
>> * Steve Ellcey <sellcey@caviumnetworks.com> [2016-12-28 10:17:50 -0800]:
>> > I would still like to check in ILP32 support for aarch64 before the
>> > code freeze deadline.  I haven't gotten any objections to the last
>> > two patches that I submitted:
>> >
>> >     https://sourceware.org/ml/libc-alpha/2016-12/msg00744.html
>> >     https://sourceware.org/ml/libc-alpha/2016-12/msg00778.html
>> >
>> > Can I check these in?  Cc'ing the aarch64 machine maintainer and the
>> > release manager.
>>
>> the aarch64 maintainer is Marcus Shawcroft
>>
>> these patches contain kernel abi details which should
>> ideally be tested and acked by linux devs as described in
>>
>> https://lkml.org/lkml/2016/12/5/333
>>
>> so only merge after both glibc and linux are ok with the abi.
>> (i think glibc is ok with the abi, but the linux maintainers
>> haven't finished review and testing yet.)
>
> https://lkml.org/lkml/2016/10/21/883
>
> This is last kernel patches in LKML, and you can find there links on
> discussions on previous submissions. ABI takes major part of discussion,
> and now after many reworks it is looking stable. At least Arnd Bergman
> and Catalin Marinas agree with current ABI.
>
> The rest of Catalin's list is here:
>
>> `1. Complete the review of the Linux patches and ABI (no merge yet)
>
> Soon, I'll update kernel submission on top of current linux-next. No ABI
> changes expected.
>
>> `2. Review the corresponding glibc patches (no merge yet)
>
> Doing right here
>
>> `3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more
>> `   than just busybox) to be able to reproduce the testing in ARM
>
> https://lkml.org/lkml/2016/12/11/45
>
>> `4. More testing (LTP, trinity, performance regressions etc.)
>
> Performance, LTP, trinity and glibc testsuites are ran, and
> some regressions found comparing to lp64, but nothing critical
> there. For example, LTP shows ~5 extra fails, and most of them
> are due to weird fail of mkfs tool, which is called in that
> tests. Trinity is OK to me, and performance in lp64 is looking
> the same - some tests little faster, some little slower, all in
> 5% range.
>
>> `5. Move the ILP32 PCS out of beta (based on the results from 4)
>
> Current kernel submission is RFC only because we have choice how to
> clear top halves of input registers. It also affects ABI a little.
> Next submission will not be RFC because current approach here is for
> more than half a year, and no critical objections found till now.
>
>> `6. Check the market again to see if anyone still needs ILP32
>
> Cavium, Huawei and Linaro wait for it. Do we need more?

I will add, MontaVista has a customer who wants it too.  This is a non
Cavium customer too.

Thanks,
Andrew

>
>> `7. Based on 6, decide whether to merge the kernel and glibc
>> `   patche
>
> -----
>
> Is all I wrote above correct from glibc and kernel maintainers point
> of view? Is there anything else to check for ILP32 to continue with
> taking it into upstream?
>
> Arnd? Catalin?
>
> Yury