Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1621172 > unrolled thread

Re: [PATCH v7 resend 00/20] ILP32 for ARM64

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v7 resend 00/20] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2017-04-11 13:40 +0200
    Re: [PATCH v7 resend 00/20] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2017-04-11 14:00 +0200
    Re: [PATCH v7 resend 00/20] ILP32 for ARM64 Florian Weimer <fweimer@redhat.com> - 2017-04-11 20:50 +0200

#1621172 — Re: [PATCH v7 resend 00/20] ILP32 for ARM64

On Mon, Apr 10, 2017 at 11:47:40PM +0400, Yury Norov wrote:
> According to latest plans figured out on Linaro Connect, ILP32 should
> be taken in 4.12 merge window.

Sorry, I wasn't present at Linaro Connect, so definitely not involved in
such decision.

BTW, it would be nice to have Arnd's ack on patch 2 (32-bit ABI:
introduce ARCH_32BIT_OFF_T config option).

> The window will be opened in less than a month, so I'd like to remind
> it to you, and ask if you have any questions/requests related to
> ILP32. Is it still realistic idea to take patches in 4.12? 

4.12 is not realistic and I wouldn't commit to a specific kernel
version. Given the intrusiveness, such patches should sit in -next for
at least 3-4 weeks (i.e. merged in the arch tree around -rc3).

Anyway, I don't think the plan has changed since last time I stated it:

https://lkml.org/lkml/2016/12/5/333

I haven't got the chance to test these patches yet, run benchmarks (step
4). Also, the latest benchmarks I've seen were mostly for user space
while I'm more concerned with the user-kernel interface
(https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). Is there
an up to date pre-built toolchain and a filesystem for ILP32?

On the glibc testing side, have the regressions been identified/fixed?

-- 
Catalin

[toc] | [next] | [standalone]

#1621190

On Apr 11 2017, Catalin Marinas <catalin.marinas@arm.com> wrote:

> Is there an up to date pre-built toolchain and a filesystem for ILP32?

https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
should have everything you need.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[toc] | [prev] | [next] | [standalone]

#1621550

On 04/11/2017 08:36 PM, Yury Norov wrote:
>> Also, the latest benchmarks I've seen were mostly for user space
>> while I'm more concerned with the user-kernel interface
>> (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2).
>
>> On the glibc testing side, have the regressions been identified/fixed?
>
> I run LTP for testing the ABI and kernel, and there is no failures in
> ltplite scenario. With glibc testsuite, there's only 3 failures
> comparing to lp64. (Steve, fix me if something changed.) This is
> slides on ilp32 from Linaro Connect, hope you'll find it useful.
>
> https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing

The listed failures are:

misc/tst-sync_file_range
nptl/tst-stack4
malloc/tst-mallocstate

If necessary, I will fix malloc/tst-mallocstate once there's support for 
a new architecture in build-many-glibcs.py.  The failure is 
architecture-independent, it's related to the lack of a compat symbol 
and the difficulty of checking for that at the Makefile or test level.

nptl/tst-stack4 is also a generic failure, I think.

misc/tst-sync_file_range is probably a real failure related to argument 
passing.  I think this system call was problematic on other 
architectures, too.

Thanks,
Florian

(Sorry for the wide Cc: list despite the glibc content.)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web