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


Groups > linux.kernel > #1345942 > unrolled thread

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

Started byAndreas Schwab <schwab@suse.de>
First post2016-02-29 17:10 +0100
Last post2016-02-29 17:40 +0100
Articles 2 — 2 participants

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: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2016-02-29 17:10 +0100
    Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-02-29 17:40 +0100

#1345942 — Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

FromAndreas Schwab <schwab@suse.de>
Date2016-02-29 17:10 +0100
SubjectRe: [RFC5 PATCH v6 00/21] ILP32 for ARM64
Message-ID<r7yyv-5hu-39@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Arnd Bergmann <arnd@arndb.de> writes:

> In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
> you are defining a struct __kernel_stat64 in the glibc. Is this the expected
> way to do it? I would have thought you'd get the definition from the kernel
> headers.

The problem really is that struct stat64 does not match the kernel
struct stat64.  The latter uses the broken st_ino, where the 64-bit
inode is actually stored at the end of the structure, and there is
padding *before* the 32-bit inode, not after (so you cannot overlay a
64-bit inode field in little endian mode).  You need to add the attached
file as sysdeps/unix/sysv/linux/aarch64/bits/stat.h, then you can use
the user-space struct stat64 to communicate with the *stat64 syscalls,
and __kernel_stat64 is not needed any more.

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] | [next] | [standalone]


#1345983

FromArnd Bergmann <arnd@arndb.de>
Date2016-02-29 17:40 +0100
Message-ID<r7z1x-5sW-41@gated-at.bofh.it>
In reply to#1345942
On Monday 29 February 2016 17:00:29 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
> > you are defining a struct __kernel_stat64 in the glibc. Is this the expected
> > way to do it? I would have thought you'd get the definition from the kernel
> > headers.
> 
> The problem really is that struct stat64 does not match the kernel
> struct stat64.  The latter uses the broken st_ino, where the 64-bit
> inode is actually stored at the end of the structure, and there is
> padding *before* the 32-bit inode, not after (so you cannot overlay a
> 64-bit inode field in little endian mode).  You need to add the attached
> file as sysdeps/unix/sysv/linux/aarch64/bits/stat.h, then you can use
> the user-space struct stat64 to communicate with the *stat64 syscalls,
> and __kernel_stat64 is not needed any more.
> 

Ok, got it. So this is an unfortunate side-effect of using the same
'stat64' as arm32 does.

If it's really that broken, should we change the kernel (once more)
to use the layout of arm64 instead? That has the 64-bit time fields
though, so it might require similar hacks, unless we first merge
support for 64-bit time_t based syscalls (which seems unlikely
at this point, sorry for the delay on my end).

Is there possibly a way to reference the implementation that we
have for stat64 on arm32 rather than duplicating it?

	Arnd

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web