[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4389139.prTLIyjV9Z@wuerfel>
Date: Mon, 16 Nov 2015 12:40:35 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Joseph Myers <joseph@...esourcery.com>
Cc: Chris Metcalf <cmetcalf@...hip.com>,
linux-arm-kernel@...ts.infradead.org, bamvor.zhangjian@...wei.com,
Andrew Pinski <pinskia@...il.com>,
"Kapoor, Prasun" <Prasun.Kapoor@...iumnetworks.com>,
Andreas Schwab <schwab@...e.de>,
Nathan Lynch <Nathan_Lynch@...tor.com>,
LKML <linux-kernel@...r.kernel.org>,
Alexander Graf <agraf@...e.de>,
Alexey Klimov <klimov.linux@...il.com>, broonie@...nel.org,
Yury Norov <ynorov@...iumnetworks.com>,
Andrew Pinski <apinski@...ium.com>,
David Daney <ddaney.cavm@...il.com>,
Catalin Marinas <catalin.marinas@....com>,
Jan Dakinevich <jan.dakinevich@...il.com>,
Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
Andrey Konovalov <andrey.konovalov@...aro.org>,
christoph.muellner@...obroma-systems.com,
Mike Frysinger <vapier@...too.org>,
Paul Eggert <eggert@...ucla.edu>, Rich Felker <dalias@...c.org>
Subject: Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
On Monday 16 November 2015 11:12:08 Joseph Myers wrote:
> On Mon, 16 Nov 2015, Arnd Bergmann wrote:
>
> > Let's not get into the tv_nsec discussion today, that is not thankfully
> > not relevant for arm64 any more at this point. The system call ABI for
> > arm64/ilp32 is now the same as for any other 32-bit architecture using
> > the generic ABI, the question we're trying to solve here is only whether it
> > is ok for new 32-bit glibc ports to only offer a 64-bit off_t as the kernel
> > currently does (using __kernel_loff_t) or if we still need to support the
> > _FILE_OFFSET_BITS=32 case.
> >
> > If I got you right, we can use 64-bit off_t now, so we just need someone
> > to figure out how to make that the default in glibc for new architectures
> > while keeping the existing 32-bit architectures unchanged.
>
> It would be an entirely new combination. Presumably such a port would
> want the "function X is an alias of function Y" aspects of wordsize-64
> directories (where that relates to off_t, struct stat etc. as opposed to
> long and long long), and the "registers are 64-bit so 64-bit operations
> are efficient" aspects, but not all the "64-bit syscall interface"
> aspects, so someone would need to review wordsize-64 sysdeps files and
> figure out what is or is not relevant to this port.
There are two separate aspects here:
a) leave out the support for all __off_t based syscalls (__ftruncate,
__lseek, __lxstat, __pread, __preadv, __pwrite, __pwritev, __truncate,
__xstat) as they are no longer needed, and change the handling of
_FILE_OFFSET_BITS so that we default to 64 and error out for anything
else.
This needs to be done for all new 32-bit architectures if you think we
should use a 64-bit off_t from now on, it's not arm64 specific.
b) For an arbitrary subset of these, introduce optimized versions that
are architecture specific and take advantage of the fact that we can
pass 64-bit register arguments on arm64-ilp32.
This is only needed because we diverge from the generic ABI in order
to avoid the silliness of splitting up a 64-bit argument and then
re-assembling it in the kernel.
This should not be needed in the generic ABI and could just live in
sysdeps/unix/sysv/linux/aarch64/wordsize-32, just like we have
special handling for each one in the arm64 in the kernel code for them.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists