* Re: FW: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
[not found] ` <BY2PR07MB23110A53F68F80960FCBD123935C0@BY2PR07MB2311.namprd07.prod.outlook.com>
@ 2016-06-06 20:39 ` Yury Norov
0 siblings, 0 replies; only message in thread
From: Yury Norov @ 2016-06-06 20:39 UTC (permalink / raw)
To: Manuel A. Fernandez Montecelo, Pinski, Andrew
Cc: Norov, Yuri, arnd, catalin.marinas, linux-kernel, schwidefsky,
szabolcs.nagy, bamvor.zhangjian
On Mon, Jun 06, 2016 at 10:03:49PM +0300, Pinski, Andrew wrote:
> You may also want to look into this thread. It just got started too.
>
> -----Original Message-----
> From: Andrew Pinski [mailto:pinskia@gmail.com]
> Sent: Monday, June 6, 2016 12:03 PM
> To: Pinski, Andrew <Andrew.Pinski@cavium.com>
> Subject: Fwd: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
>
> ---------- Forwarded message ----------
> From: Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
> Date: Mon, Jun 6, 2016 at 11:51 AM
> Subject: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
> To: libc-alpha@sourceware.org
>
>
> Hi,
>
> When discussing how to implement these types for the RISC-V architecture (32,
> 64 and 128-bit flavours), it seems that there's a drive [1][2] to force new
> arches to use the 64-bit versions of these types (so they would be the same
> as __OFF64_T_TYPE and __INO64_T_TYPE), even for 32-bit arches.
>
> Does this look like a reasonable approach?
>
> https://github.com/manuelafm/riscv-gnu-toolchain/commit/764f5ac958618c1ca8761845864164365282ffbd
>
> (also attached)
>
Hi Manuel,
It seems, we are working on the same issue. AARCH64/ilp32 ABI is going to work
the way you described below. I found next types to be turned to 64-bit
[https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1157969.html]:
> So for AARCH64/ILP32 we turn next types to 64-bit in glibc:
> #define __INO_T_TYPE __UQUAD_TYPE
> #define __OFF_T_TYPE __SQUAD_TYPE
> #define __BLKCNT_T_TYPE __SQUAD_TYPE
> #define __FSBLKCNT_T_TYPE __UQUAD_TYPE
> #define __FSFILCNT_T_TYPE __UQUAD_TYPE
>
> And define:
> # define __INO_T_MATCHES_INO64_T 1
> # define __OFF_T_MATCHES_OFF64_T 1
> # define __BLKCNT_T_MATCHES_BLKCNT64_T 1
> # define __FSBLKCNT_T_MATCHES_FSBLKCNT64_T 1
> # define __FSFILCNT_T_MATCHES_FSFILCNT_T 1
>
> If so, stat and statfs structures for ilp32 are turning the same as
> for lp64. And so we'd handle related syscalls with native lp64
> handlers (wrapped, to zero top halves) in kernel.
^^^ The main goal ^^^
>
> And we don't need stat64 for ilp32.
>
> Did I miss something? Is everything correct?
>
> https://github.com/norov/glibc/commits/ilp32-dev
> https://github.com/norov/linux/commits/ilp32
>
Under links below you can find my current progress on this work.
Also notice how I redeclared struct timespec.
#ifdef timespec_needs_pads
# if __BYTE_ORDER == __LITTLE_ENDIAN
struct timespec
{
__time_t tv_sec; /* Seconds. */
int sec_pad;
__syscall_slong_t tv_nsec; /* Nanoseconds. */
int nsec_pad;
};
# else
struct timespec
{
int sec_pad;
__time_t tv_sec; /* Seconds. */
int nsec_pad;
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
# endif
#else
struct timespec
{
__time_t tv_sec; /* Seconds. */
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
#endif /* timespec_needs_pads */
I'm little worry about correctness of this approach. But if you define the whole
new RISC-V arch, I think, new timeskpec is OK there.
BTW, just curious, why RISK-V. I think it will work for CISC as well. And what '-V'
means?
Yury.
>
> [1] At least from people in the Linux kernel community.
>
> [2] A further suggestion was that all new arches should default to have
> the same width for these types, 64 bits, and override __OFF_T_TYPE
> and __INO_T_TYPE for all the existing architectures where they are
> currently 32-bits. I don't know if this is desirable at this point.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
^ permalink raw reply [flat|nested] only message in thread