This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fallocate: pass off_t in register pair correctly for 64-bit off_t

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[1] in favor of 32-bit off_t emulation in glibc
beyond the fact that someone has to do the work to implement the new
default once.

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.


[1] 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]