This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Yury Norov <ynorov at caviumnetworks dot com>, libc-alpha at sourceware dot org, schwab at suse dot de, catalin dot marinas at arm dot com, davem at davemloft dot net, szabolcs dot nagy at arm dot com, maxim dot kuvyrkov at linaro dot org, pinskia at gmail dot com, bamvor dot zhangjian at huawei dot com, fweimer at redhat dot com, Prasun dot Kapoor at cavium dot com, adhemerval dot zanella at linaro dot org
- Date: Tue, 09 Aug 2016 23:17:59 +0200
- Subject: Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family
- Authentication-results: sourceware.org; auth=none
- References: <1470304959-9944-1-git-send-email-ynorov@caviumnetworks.com> <61480577.oYI5jpLnz4@wuerfel> <alpine.DEB.2.20.1608092100100.11410@digraph.polyomino.org.uk>
On Tuesday, August 9, 2016 9:03:54 PM CEST Joseph Myers wrote:
> On Tue, 9 Aug 2016, Arnd Bergmann wrote:
>
> > We cannot define 'struct timespec' to be incompatible with the version
> > used by the kernel, that would break all other interfaces passing a
> > timespec.
> >
> > While in theory the kernel could change the definition of its "compat"
> > data types for 32-bit tasks on 64-bit kernels (as it does for x86/x32),
> > we are not doing that for aarch64, in order to stay compatible with
> > device drivers that already have working compat mode on 32-bit ARM.
>
> So in that case, if the kernel's struct stat uses 64-bit timespec, it's
> inevitably different from the userspace timespec. Which leaves me
> wondering what the advantages of a userspace layout that's almost but not
> quite the same as the kernel's layout (and so needs timespec fields
> rearranged on structs received from the kernel) are over not doing
> anything special about the timespec fields in the userspace struct
> definition (that is, no special padding / alignment) and instead using the
> existing machinery for converting struct stat to convert from the kernel
> structure to the userspace structure.
Right, that would be what I listed as approach a) in my mail with
message id 1914420.rMinRNpl2s@wuerfel earlier today, i.e. the
easiest way to solve the problem.
Arnd