This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Mike Frysinger <vapier at gentoo dot org>, Yury Norov <ynorov at caviumnetworks dot com>, cmetcalf at tilera dot com, pinskia at gmail dot com, cmetcalf at mellanox dot com, joseph at codesourcery dot com
- Date: Fri, 24 Jun 2016 21:53:19 +0200
- Subject: Re: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t
- Authentication-results: sourceware.org; auth=none
- References: <1466746995-25982-1-git-send-email-ynorov at caviumnetworks dot com> <20160624085224 dot GA13117 at yury-N73SV> <20160624161552 dot GH24532 at vapier dot lan>
On Friday, June 24, 2016 12:15:52 PM CEST Mike Frysinger wrote:
> On 24 Jun 2016 11:52, Yury Norov wrote:
> > On Fri, Jun 24, 2016 at 04:30:23AM -0400, Mike Frysinger wrote:
> > > On 24 Jun 2016 08:43, Yury Norov wrote:
> > > > sysdeps/unix/sysv/linux/fallocate.c contains wide-spreaded hack for creating
> > > > register pair from 32-bit signed value:
> > > > LONG_LONG_PAIR (val >> 31, val)
> > > >
> > > > It works well for off_t if it is 32-bit lenght. Modern ABIs requres 64-bit off_t,
> > > > so this hack doesn't work for them. In this patch, fallocate handler is taken from
> > > > fallocate64.c, depending on __OFF_T_MATCHES_OFF64_T.
> > >
> > > what ABIs exactly are you referring to ?
> > AARCH64/ILP32. It would be any modern 32-bit API, as off_t should be
> > 64-bit for them
> ignoring ILP32 ABIs (which are running on native 64-bit hardware and have
> full access to the 64-bit registers), no new 32-bit port is being defined
> with 64-bit off_t types. they follow existing style where LFS is used.
> whether we want to change all 32-bit ports to be LFS-enabled by default is
> a different question ... we'd still want them to be consistent.
I've been pushing the move for 64-bit off_t for both RISC-V and ARM64/ILP32,
mainly because it seems like the right thing to do (the kernel has stopped
supporting 32-bit off_t for new architectures many years ago), and there
were no technical arguments in favor of 32-bit off_t emulation in glibc
beyond the fact that someone has to do the work to implement the new
If you feel strongly about it for some reason, I guess we can go back to
defaulting to 32-bit off_t on aarch64/ilp32, but I absolutely agree that
we want to be consistent here, and then we should do the same on RISC-V.
 actually one argument in favor of 32-bit off_t would be to wait until
the kernel can also do 64-bit time_t on all architectures, and then change
both at the same time for all architectures merged after that point.