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

Groups > linux.kernel > #1261055 > unrolled thread

[RFC PATCH v6 00/17] ILP32 for ARM64

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH v6 00/17] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 03/17] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 04/17] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 10/17] arm64:ilp32: support core dump generation for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 08/17] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 14/17] aarch64: ilp32: use generic stat64 structure Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 14/17] aarch64: ilp32: use generic stat64 structure Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:20 +0100
    [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:40 +0100
    [PATCH v6 11/17] ptrace: Allow compat to use the native siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 11/17] ptrace: Allow compat to use the native siginfo Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:00 +0100
    [PATCH v6 15/17] arm64:ilp32: use the native siginfo instead of the compat siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 07/17] arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-05 15:00 +0100
      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-11 19:00 +0100
        Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-11 21:50 +0100
          Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 00:10 +0100
            Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 00:30 +0100
              Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 10:00 +0100
                Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 10:30 +0100
                  Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 10:50 +0100
                    Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-12 14:30 +0100
                      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-12 14:50 +0100
                        Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-13 16:40 +0100
                          Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Andrew Pinski <pinskia@gmail.com> - 2015-11-13 16:40 +0100
                            Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-13 17:20 +0100
                              Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-15 16:20 +0100
                                Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Joseph Myers <joseph@codesourcery.com> - 2015-11-16 11:20 +0100
                                  Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-16 12:10 +0100
                                    Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Joseph Myers <joseph@codesourcery.com> - 2015-11-16 12:20 +0100
                                      Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-16 12:50 +0100
                                        Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Joseph Myers <joseph@codesourcery.com> - 2015-11-16 13:10 +0100
                                          Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-16 13:20 +0100
                                            Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Joseph Myers <joseph@codesourcery.com> - 2015-11-16 13:40 +0100
                                              Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-16 14:20 +0100
                                                Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-16 14:40 +0100
                                                  Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-16 15:00 +0100
    [PATCH v6 17/17] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-11-03 00:40 +0100
    Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-05 12:40 +0100
      Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andrew Pinski <pinskia@gmail.com> - 2015-11-05 14:50 +0100
        Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 11:10 +0100
          Re: [RFC PATCH v6 00/17] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2015-11-11 08:30 +0100
            Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-11 09:50 +0100
        Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 14:30 +0100
          Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-09 15:30 +0100
            Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-09 15:40 +0100
              Re: [RFC PATCH v6 00/17] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2015-11-09 15:40 +0100
                Re: [RFC PATCH v6 00/17] ILP32 for ARM64 pinskia@gmail.com - 2015-11-09 16:10 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1267746 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 09:58:43 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > I think either way is fine for the two examples. I think it's clear
> > that we want __NR_llseek as 62 and __NR_mmap2 as 222. Whether those
> > use the compat_sys_llseek/compat_sys_mmap2_wrapper or
> > sys_lseek/sys_mmap entry points is not overly important, we can use
> > whatever is more convenient to glibc: if we can kill off an
> > architecture specific wrapper function in glibc by adding one line
> > to the kernel, that seems worthwhile.
> 
> Currently most off_t-like syscalls need a new glibc wrapper since the
> existing ones are either for 32bit off_t+off64_t (with split off64_t
> syscall arguments) or pure 64bit off_t architectures.  Since ilp32 now
> (mostly) has 32bit off_t, but 64bit off_t-like syscalls neither of them
> fit.

What do you mean with 32-bit off_t? Do you mean that glibc emulates
a 32-bit off_t on top of the 64-bit __kernel_loff_t? That sounds a bit
backwards. I would expect that all new architectures that only have
__kernel_loff_t based syscalls but not __kernel_off_t based ones only
ever use a 64-bit off_t in libc.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1267756 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> What do you mean with 32-bit off_t?

An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.

> Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> __kernel_loff_t?

Glibc is bridging the user-space ABI to the kernel ABI.

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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1267907 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > What do you mean with 32-bit off_t?
> 
> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> 
> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> > __kernel_loff_t?
> 
> Glibc is bridging the user-space ABI to the kernel ABI.

Ok, but why?

The kernel headers for all recent architectures (arc, c6x, h8300,
hexagon, metag, nios2, openrisc, tile and unicore32) deliberately
leave out the __kernel_off_t based system calls to simplify the
ABI in a way that we never have to support a 32-bit off_t
in user space.

Are there programs that require using a 32-bit off_t by default
on 32-bit architectures but not on 64-bit architectures?
Did the previous version of the ilp32 patch set also emulate
this the same way?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1267935 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> 
>> > What do you mean with 32-bit off_t?
>> 
>> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
>> 
>> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
>> > __kernel_loff_t?
>> 
>> Glibc is bridging the user-space ABI to the kernel ABI.
>
> Ok, but why?

That's how the ABI is defined right now.  I didn't make that up.

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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1269025 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> 
> >> > What do you mean with 32-bit off_t?
> >> 
> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> >> 
> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> >> > __kernel_loff_t?
> >> 
> >> Glibc is bridging the user-space ABI to the kernel ABI.
> >
> > Ok, but why?
> 
> That's how the ABI is defined right now.  I didn't make that up.

Ok, I guess it will remain a mystery then.

Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
file then, so we provide both the off_t and the loff_t based syscalls?

That would avoid the extra wrapper in glibc when using a 32-bit
off_t if that is the preferred mode for user space.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1269027 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
>> >> Arnd Bergmann <arnd@arndb.de> writes:
>> >>
>> >> > What do you mean with 32-bit off_t?
>> >>
>> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
>> >>
>> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
>> >> > __kernel_loff_t?
>> >>
>> >> Glibc is bridging the user-space ABI to the kernel ABI.
>> >
>> > Ok, but why?
>>
>> That's how the ABI is defined right now.  I didn't make that up.
>
> Ok, I guess it will remain a mystery then.

The biggest question is here is how much compatibility do we want with
other 32bit ABIs?
Do we want off_t to be 32bit or 64bit?

>
> Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
> file then, so we provide both the off_t and the loff_t based syscalls?

I think that is backwards ...

>
> That would avoid the extra wrapper in glibc when using a 32-bit
> off_t if that is the preferred mode for user space.


Other targets like tilegx does not do that and has a pure 32bit mode.
Only score does that.

Thanks,
Andrew

>
>         Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1269052 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 13 November 2015 07:38:49 Andrew Pinski wrote:
> On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >>
> >> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> >> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> >>
> >> >> > What do you mean with 32-bit off_t?
> >> >>
> >> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> >> >>
> >> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> >> >> > __kernel_loff_t?
> >> >>
> >> >> Glibc is bridging the user-space ABI to the kernel ABI.
> >> >
> >> > Ok, but why?
> >>
> >> That's how the ABI is defined right now.  I didn't make that up.
> >
> > Ok, I guess it will remain a mystery then.
> 
> The biggest question is here is how much compatibility do we want with
> other 32bit ABIs?
> Do we want off_t to be 32bit or 64bit?

I would much prefer off_t to be defined as __kernel_loff_t unconditionally,
with no support for _FILE_OFFSET_BITS == 32. This is at least what I had
in mind when I wrote the asm-generic/unistd.h header.

We should probably find out what happened for the other glibc ports that
were implemented for the architectures using this. It's possible that
there was a good reason for supporting _FILE_OFFSET_BITS == 32 at the
time, but I can't think of one and maybe it is one that is no longer
valid.

Do you know what x86/x32 does for off_t? Do they also implement both
_FILE_OFFSET_BITS == 32 and _FILE_OFFSET_BITS == 64 on top of the
64-bit __kernel_off_t?

> > Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h
> > file then, so we provide both the off_t and the loff_t based syscalls?
> 
> I think that is backwards ...
> 
> >
> > That would avoid the extra wrapper in glibc when using a 32-bit
> > off_t if that is the preferred mode for user space.
> 
> 
> Other targets like tilegx does not do that and has a pure 32bit mode.
> Only score does that.

score was unintentional, it was the first port that got done after we
introduced the generic headers, and they said at the time that they
would change their libc to remove the dependency on the legacy syscalls,
but when I tried to remove them later, they had already shipped it
with them enabled. After that, I told people to never enable the
symbols in an upstream port and only use them for porting their libc
internally. We could actually now move all the legacy syscall stuff
to arch/score/include/uapi/asm/unistd.h, to prevent anyone else from
using it any longer, as glibc works fine without them these days.

The __ARCH_WANT_SYSCALL_OFF_T define might be an exception. If the glibc
developers want to keep using 32-bit off_t by default on all new
architecture, we could include those calls again by default.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1269709 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Friday 13 November 2015 17:10:44 Arnd Bergmann wrote:
> On Friday 13 November 2015 07:38:49 Andrew Pinski wrote:
> > On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote:
> > >> Arnd Bergmann <arnd@arndb.de> writes:
> > >>
> > >> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote:
> > >> >> Arnd Bergmann <arnd@arndb.de> writes:
> > >> >>
> > >> >> > What do you mean with 32-bit off_t?
> > >> >>
> > >> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs.
> > >> >>
> > >> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit
> > >> >> > __kernel_loff_t?
> > >> >>
> > >> >> Glibc is bridging the user-space ABI to the kernel ABI.
> > >> >
> > >> > Ok, but why?
> > >>
> > >> That's how the ABI is defined right now.  I didn't make that up.
> > >
> > > Ok, I guess it will remain a mystery then.
> > 
> > The biggest question is here is how much compatibility do we want with
> > other 32bit ABIs?
> > Do we want off_t to be 32bit or 64bit?
> 
> I would much prefer off_t to be defined as __kernel_loff_t unconditionally,
> with no support for _FILE_OFFSET_BITS == 32. This is at least what I had
> in mind when I wrote the asm-generic/unistd.h header.
> 
> We should probably find out what happened for the other glibc ports that
> were implemented for the architectures using this. It's possible that
> there was a good reason for supporting _FILE_OFFSET_BITS == 32 at the
> time, but I can't think of one and maybe it is one that is no longer
> valid.
> 
> Do you know what x86/x32 does for off_t? Do they also implement both
> _FILE_OFFSET_BITS == 32 and _FILE_OFFSET_BITS == 64 on top of the
> 64-bit __kernel_off_t?

I just did a little bit of digging through glibc history and found that
Chris Metcalf added the files that are now in
sysdeps/unix/sysv/linux/generic/wordsize-32/ and that provide the
implementation for 32-bit off_t in glibc on top of the 64-bit
__kernel_off_t.

Chris, do you remember what led to that? Do you think we still need
to have 32-bit off_t on all new architectures, or could we move
on to making 64-bit off_t the default when adding a port?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1269968 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Sun, 15 Nov 2015, Chris Metcalf wrote:

> I've added Rich, Paul, Joseph, and Mike to the cc's as they are probably 
> a good subset of libc-alpha to help comment on these issues.  My sense 
> is that right now, it wouldn't be possible to add a 32-bit architecture 
> with a non-32-bit default for _FILE_OFFSET_BITS.  And, obviously, this 
> is why, when I added the tilegx32 APIs to glibc in 2011, I needed to 
> provide _FILE_OFFSET_BITS=32 support.

x32 uses 64-bit off_t only.  That's not a problem; the problems are 
tv_nsec not of type long, a bug we should avoid for all new ports (padding 
on tv_nsec is fine; treating that padding as a significant high part of a 
64-bit value on input to glibc / kernel interfaces isn't), and maybe some 
other types being 64-bit unnecessarily, although as far as I know the 
suggested issues there 
<https://sourceware.org/bugzilla/show_bug.cgi?id=16438> are all 
theoretical.

It's true that we don't have a very clear notion of what "wordsize-64" 
sysdeps directories mean in glibc for cases such as x32.  See 
<https://sourceware.org/bugzilla/show_bug.cgi?id=14116>.

-- 
Joseph S. Myers
joseph@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270003 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 16 November 2015 10:16:35 Joseph Myers wrote:
> On Sun, 15 Nov 2015, Chris Metcalf wrote:
> 
> > I've added Rich, Paul, Joseph, and Mike to the cc's as they are probably 
> > a good subset of libc-alpha to help comment on these issues.  My sense 
> > is that right now, it wouldn't be possible to add a 32-bit architecture 
> > with a non-32-bit default for _FILE_OFFSET_BITS.  And, obviously, this 
> > is why, when I added the tilegx32 APIs to glibc in 2011, I needed to 
> > provide _FILE_OFFSET_BITS=32 support.
> 
> x32 uses 64-bit off_t only.  That's not a problem; the problems are 
> tv_nsec not of type long, a bug we should avoid for all new ports (padding 
> on tv_nsec is fine; treating that padding as a significant high part of a 
> 64-bit value on input to glibc / kernel interfaces isn't), and maybe some 
> other types being 64-bit unnecessarily, although as far as I know the 
> suggested issues there 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16438> are all 
> theoretical.

Let's not get into the tv_nsec discussion today, that is not thankfully
not relevant for arm64 any more at this point. The system call ABI for
arm64/ilp32 is now the same as for any other 32-bit architecture using
the generic ABI, the question we're trying to solve here is only whether it
is ok for new 32-bit glibc ports to only offer a 64-bit off_t as the kernel
currently does (using __kernel_loff_t) or if we still need to support the
_FILE_OFFSET_BITS=32 case.

If I got you right, we can use 64-bit off_t now, so we just need someone
to figure out how to make that the default in glibc for new architectures
while keeping the existing 32-bit architectures unchanged.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270016 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote:

> Let's not get into the tv_nsec discussion today, that is not thankfully
> not relevant for arm64 any more at this point. The system call ABI for
> arm64/ilp32 is now the same as for any other 32-bit architecture using
> the generic ABI, the question we're trying to solve here is only whether it
> is ok for new 32-bit glibc ports to only offer a 64-bit off_t as the kernel
> currently does (using __kernel_loff_t) or if we still need to support the
> _FILE_OFFSET_BITS=32 case.
> 
> If I got you right, we can use 64-bit off_t now, so we just need someone
> to figure out how to make that the default in glibc for new architectures
> while keeping the existing 32-bit architectures unchanged.

It would be an entirely new combination.  Presumably such a port would 
want the "function X is an alias of function Y" aspects of wordsize-64 
directories (where that relates to off_t, struct stat etc. as opposed to 
long and long long), and the "registers are 64-bit so 64-bit operations 
are efficient" aspects, but not all the "64-bit syscall interface" 
aspects, so someone would need to review wordsize-64 sysdeps files and 
figure out what is or is not relevant to this port.

-- 
Joseph S. Myers
joseph@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270042 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 16 November 2015 11:12:08 Joseph Myers wrote:
> On Mon, 16 Nov 2015, Arnd Bergmann wrote:
> 
> > Let's not get into the tv_nsec discussion today, that is not thankfully
> > not relevant for arm64 any more at this point. The system call ABI for
> > arm64/ilp32 is now the same as for any other 32-bit architecture using
> > the generic ABI, the question we're trying to solve here is only whether it
> > is ok for new 32-bit glibc ports to only offer a 64-bit off_t as the kernel
> > currently does (using __kernel_loff_t) or if we still need to support the
> > _FILE_OFFSET_BITS=32 case.
> > 
> > If I got you right, we can use 64-bit off_t now, so we just need someone
> > to figure out how to make that the default in glibc for new architectures
> > while keeping the existing 32-bit architectures unchanged.
> 
> It would be an entirely new combination.  Presumably such a port would 
> want the "function X is an alias of function Y" aspects of wordsize-64 
> directories (where that relates to off_t, struct stat etc. as opposed to 
> long and long long), and the "registers are 64-bit so 64-bit operations 
> are efficient" aspects, but not all the "64-bit syscall interface" 
> aspects, so someone would need to review wordsize-64 sysdeps files and 
> figure out what is or is not relevant to this port.

There are two separate aspects here:

a) leave out the support for all __off_t based syscalls (__ftruncate,
   __lseek, __lxstat, __pread, __preadv, __pwrite, __pwritev, __truncate,
   __xstat) as they are no longer needed, and change the handling of
   _FILE_OFFSET_BITS so that we default to 64 and error out for anything
   else.
   This needs to be done for all new 32-bit architectures if you think we
   should use a 64-bit off_t from now on, it's not arm64 specific.

b) For an arbitrary subset of these, introduce optimized versions that
   are architecture specific and take advantage of the fact that we can
   pass 64-bit register arguments on arm64-ilp32.
   This is only needed because we diverge from the generic ABI in order
   to avoid the silliness of splitting up a 64-bit argument and then
   re-assembling it in the kernel.
   This should not be needed in the generic ABI and could just live in
   sysdeps/unix/sysv/linux/aarch64/wordsize-32, just like we have
   special handling for each one in the arm64 in the kernel code for them.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270051 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote:

> There are two separate aspects here:
> 
> a) leave out the support for all __off_t based syscalls (__ftruncate,
>    __lseek, __lxstat, __pread, __preadv, __pwrite, __pwritev, __truncate,
>    __xstat) as they are no longer needed, and change the handling of
>    _FILE_OFFSET_BITS so that we default to 64 and error out for anything
>    else.
>    This needs to be done for all new 32-bit architectures if you think we
>    should use a 64-bit off_t from now on, it's not arm64 specific.

It's not a matter of leaving anything out - these would simply use 64-bit 
off_t (__off_t and __off64_t would be the same type) and the *64 versions 
would be aliases, exactly the same as on 64-bit architectures.  (And 
_FILE_OFFSET_BITS handling would also be exactly the same as on 64-bit 
architectures.)  I see no reason for the set of off_t-related symbols that 
exist, or which symbols are aliases of which others, to vary between pure 
64-bit systems and ILP32 ABIs (for 32-bit or 64-bit architectures) that 
simply happen to have had 64-bit off_t from the start.

-- 
Joseph S. Myers
joseph@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270056 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 16 November 2015 12:03:09 Joseph Myers wrote:
> On Mon, 16 Nov 2015, Arnd Bergmann wrote:
> 
> > There are two separate aspects here:
> > 
> > a) leave out the support for all __off_t based syscalls (__ftruncate,
> >    __lseek, __lxstat, __pread, __preadv, __pwrite, __pwritev, __truncate,
> >    __xstat) as they are no longer needed, and change the handling of
> >    _FILE_OFFSET_BITS so that we default to 64 and error out for anything
> >    else.
> >    This needs to be done for all new 32-bit architectures if you think we
> >    should use a 64-bit off_t from now on, it's not arm64 specific.
> 
> It's not a matter of leaving anything out - these would simply use 64-bit 
> off_t (__off_t and __off64_t would be the same type) and the *64 versions 
> would be aliases, exactly the same as on 64-bit architectures.  (And 
> _FILE_OFFSET_BITS handling would also be exactly the same as on 64-bit 
> architectures.)  I see no reason for the set of off_t-related symbols that 
> exist, or which symbols are aliases of which others, to vary between pure 
> 64-bit systems and ILP32 ABIs (for 32-bit or 64-bit architectures) that 
> simply happen to have had 64-bit off_t from the start.

Ok, fair enough. So we just change the global __OFF_T_TYPE definition
in bits/typesizes.h and override it for all the existing 32-bit ports,
correct?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270071 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, 16 Nov 2015, Arnd Bergmann wrote:

> > It's not a matter of leaving anything out - these would simply use 64-bit 
> > off_t (__off_t and __off64_t would be the same type) and the *64 versions 
> > would be aliases, exactly the same as on 64-bit architectures.  (And 
> > _FILE_OFFSET_BITS handling would also be exactly the same as on 64-bit 
> > architectures.)  I see no reason for the set of off_t-related symbols that 
> > exist, or which symbols are aliases of which others, to vary between pure 
> > 64-bit systems and ILP32 ABIs (for 32-bit or 64-bit architectures) that 
> > simply happen to have had 64-bit off_t from the start.
> 
> Ok, fair enough. So we just change the global __OFF_T_TYPE definition
> in bits/typesizes.h and override it for all the existing 32-bit ports,
> correct?

Well, it's sysdeps/unix/sysv/linux/generic/bits/typesizes.h that's 
relevant - so if future generic architectures will use 64-bit off_t, I 
suppose the existing file could be cloned for existing generic 
architectures with 32-bit support.  And all the types involved in struct 
stat are affected (e.g. ino_t), not just off_t.  And getting the aliases 
right may involve disentangling the different meanings of wordsize-64 into 
different sysdeps directories.  ("off_t is off64_t" and "stat is stat64" 
are not the same thing.  See MIPS n64.)  And the design work needs to be 
done on libc-alpha, not in a random discussion elsewhere.

-- 
Joseph S. Myers
joseph@codesourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270107 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 16 November 2015 12:34:55 Joseph Myers wrote:
> On Mon, 16 Nov 2015, Arnd Bergmann wrote:
> 
> > > It's not a matter of leaving anything out - these would simply use 64-bit 
> > > off_t (__off_t and __off64_t would be the same type) and the *64 versions 
> > > would be aliases, exactly the same as on 64-bit architectures.  (And 
> > > _FILE_OFFSET_BITS handling would also be exactly the same as on 64-bit 
> > > architectures.)  I see no reason for the set of off_t-related symbols that 
> > > exist, or which symbols are aliases of which others, to vary between pure 
> > > 64-bit systems and ILP32 ABIs (for 32-bit or 64-bit architectures) that 
> > > simply happen to have had 64-bit off_t from the start.
> > 
> > Ok, fair enough. So we just change the global __OFF_T_TYPE definition
> > in bits/typesizes.h and override it for all the existing 32-bit ports,
> > correct?
> 
> Well, it's sysdeps/unix/sysv/linux/generic/bits/typesizes.h that's 
> relevant - so if future generic architectures will use 64-bit off_t, I 
> suppose the existing file could be cloned for existing generic 
> architectures with 32-bit support. 

Ok, got it.

> And all the types involved in struct stat are affected (e.g. ino_t),
> not just off_t. 

ino_t seems to be the only other type in 'struct stat' that depends
on _FILE_OFFSET_BITS in glibc. On the kernel side, we don't care about
__kernel_ino_t any more, we just leave that defined as 'unsigned long'
while using a plain 'unsigned long long' for 'st_ino' in struct stat64
(and don't use __kernel_ino_t anywhere else either).

> And getting the aliases 
> right may involve disentangling the different meanings of wordsize-64 into 
> different sysdeps directories.  ("off_t is off64_t" and "stat is stat64" 
> are not the same thing.  See MIPS n64.)  And the design work needs to be 
> done on libc-alpha, not in a random discussion elsewhere.

Sure. For the moment, we have all the information we need for the kernel
side at least: we will keep using only 64-bit __kernel_loff_t on the
system call side in new architecture ports and let you figure out how
to work with that on the glibc side whenever the next 32-bit port arrives,
which I assume will be arm64-ilp32.

The 'struct stat' discussion will of course come back soon when we get to
the 64-bit time_t patches, or when we introduce the extended stat syscall,
whichever happens first.

Thanks a lot for your help!

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270143 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> ino_t seems to be the only other type in 'struct stat' that depends
> on _FILE_OFFSET_BITS in glibc.

There is also blkcnt_t, and then there is fsblkcnt_t, fsfilcnt_t and
fsword_t in struct statfs.

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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1270184 — Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 16 November 2015 14:34:50 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > ino_t seems to be the only other type in 'struct stat' that depends
> > on _FILE_OFFSET_BITS in glibc.
> 
> There is also blkcnt_t, and then there is fsblkcnt_t, fsfilcnt_t and
> fsword_t in struct statfs.

Ok, got it.

Again these are just internal to glibc, the kernel just uses fixed width
types in

typedef struct {
        int     val[2];
} __kernel_fsid_t;

struct statfs64 {
        __u32 f_type;
        __u32 f_bsize;
        __u64 f_blocks; 
        __u64 f_bfree;  
        __u64 f_bavail;
        __u64 f_files;
        __u64 f_ffree;
        __kernel_fsid_t f_fsid;
        __u32 f_namelen;
        __u32 f_frsize;
        __u32 f_flags;
        __u32 f_spare[4];
};

so we need to be careful to define them in glibc to match the kernel
types, but the kernel definition doesn't need changes.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1261066 — [PATCH v6 17/17] arm64:ilp32: add ARM64_ILP32 to Kconfig

From: Andrew Pinski <apinski@cavium.com>

This patch adds the config option for ILP32.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Andrew Pinski <Andrew.Pinski@caviumnetworks.com>
Reviewed-by: David Daney <david.daney@cavium.com>
---
 arch/arm64/Kconfig | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d1dc605..afbde9c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -680,7 +680,7 @@ source "fs/Kconfig.binfmt"
 
 config COMPAT
 	def_bool y
-	depends on AARCH32_EL0
+	depends on AARCH32_EL0 || ARM64_ILP32
 	select COMPAT_BINFMT_ELF
 
 config AARCH32_EL0
@@ -702,6 +702,13 @@ config AARCH32_EL0
 
 	  If you want to execute 32-bit userspace applications, say Y.
 
+config ARM64_ILP32
+	bool "Kernel support for ILP32"
+	help
+	  This option enables support for AArch64 ILP32 user space.  ILP32
+	  is an ABI where long and pointers are 32bits but it uses the AARCH64
+	  instruction set.
+
 config SYSVIPC_COMPAT
 	def_bool y
 	depends on AARCH32_EL0 && SYSVIPC
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1263121

Yury Norov <ynorov@caviumnetworks.com> writes:

> v6:
>  - time_t, __kenel_off_t and other types turned to be 32-bit
>    for compatibility reasons (after v5 discussion);

Are the updated glibc patches available somewhere?

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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web