[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2016 23:39:26 +0300
From: Yury Norov <ynorov@...iumnetworks.com>
To: "Manuel A. Fernandez Montecelo" <manuel.montezelo@...il.com>,
"Pinski, Andrew" <Andrew.Pinski@...ium.com>
CC: "Norov, Yuri" <Yuri.Norov@...iumnetworks.com>, <arnd@...db.de>,
<catalin.marinas@....com>, <linux-kernel@...r.kernel.org>,
<schwidefsky@...ibm.com>, <szabolcs.nagy@....com>,
<bamvor.zhangjian@...wei.com>
Subject: Re: FW: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new
32-bit architectures?
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@...il.com]
> Sent: Monday, June 6, 2016 12:03 PM
> To: Pinski, Andrew <Andrew.Pinski@...ium.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@...il.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@...rceware.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@...il.com>
Powered by blists - more mailing lists