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: Yury Norov <ynorov at caviumnetworks dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, <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, 9 Aug 2016 18:15:43 +0300
- Subject: Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yuri dot Norov at caviumnetworks dot com;
- References: <1470304959-9944-1-git-send-email-ynorov@caviumnetworks.com> <alpine.DEB.2.20.1608051702380.10256@digraph.polyomino.org.uk> <20160809132645.GA19286@yury-N73SV> <4238761.RmIfF61nkt@wuerfel>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Tue, Aug 09, 2016 at 04:23:27PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 9, 2016 4:26:45 PM CEST Yury Norov wrote:
> > > As for struct timespec inside struct stat: are you sure that special
> > > handling in the struct stat declaration is the right thing to do, rather
> > > than arranging for this port to define struct timespec to contain the
> > > padding members and be appropriately aligned (with the kernel made to
> > > ignore the high parts when struct timespec is passed to the kernel from an
> > > ILP32 process, since those high parts are considered padding in
> > > userspace)? Putting the padding in struct timespec so the layout is
> > > genuinely compatible between userspace and the kernel would seem a lot
> > > less intrusive in glibc. (Because of the pre-__USE_XOPEN2K8 case in
> > > bits/stat.h, I suppose you'd need an implementation-namespace macro or two
> > > somewhere for defining time_t and nanoseconds fields, that macro
> > > automatically declaring the padding field as needed, and that macro then
> > > being used in bits/stat.h as well as in the original definition of struct
> > > timespec.)
> >
> > It was my initial idea, but Arnd told that we cannot modify time_t and
> > struct timespec as it is used in some ioctls and this change may harm
> > compatibility.
>
> Right. The discussion for the y2038 glibc port has progressed a bit,
> and we will in fact see a way to use 64-bit glibc time_t with a kernel
> that has 32-bit time_t for backwards compatibility reasons, but this
> is very far from being at the point where a glibc port can make that
> the only option.
>
Could you share this discussion to me?
> > I suggested to declare new time64_t and struct timespec64 and use it
> > in union with 32-bit versions where possible but it was rejected too.
> > So with 32-bit time_t/timespec, this is the only option to treat time
> > fields as special case and introduce a bunch of paddings.
>
> Let's take a step back here. We had a very long discussion about the
> kernel ABI, and in particular the definition of 'struct stat64' for
> aarch64-ilp32. To recap, there were three options (we probably had
> an implementation for each one at some point):
>
> a) use the generic definition for 'stat64' from the architecture
> independent headers: This has the downside of requiring extra
> syscall entry points in the kernel for the new ABI, as the layout
> is different from what 32-bit ARM uses, and our normal compat
> handlers provide those.
>
> b) use the definition from 32-bit ARM, and share the compat stat64
> syscalls: This has the downside of using an awkward layout that
> has the STAT64_HAS_BROKEN_ST_INO set, and has two copies of
> st_ino.
>
> c) Use the layout that is compatible with 64-bit ARM (aarch64) kernels:
> The downside here is that it does not use the standard types for
> the time stamps, so you end up having to handle it in an architecture
> specific way in user space.
>
> We ended up with approach c), which seemed the most future-proof
> ABI, but if the decision was to not use the generic ABI, why do you
> try to add this to the generic implementation? The easiest way
> would be to just have a aarch64 specific conversion function that
> copies the data from the kernel structure into the generic user
> space structure.
>
> Alternatively you can add a sysdeps/unix/sysv/linux/aarch64/bits/stat.h
> file that defines the structure the same way that the kernel does, but
> you don't need to come up with a generic way of doing this, as (almost
> certainly) no other architecture will have this problem, and we will have
> to solve the more general 64-bit time_t problem independently.
This is how it was implemented initially. But Joseph requested to
re-use generic glibc code as much as possible. In fact, if we use
64-bit off_t etc, the only difference is struct timespec, and there
are 3 options we should consider to handle it:
1. Add pads to generic structure (current).
2. Declare stat structures in arch code (initial).
3. Introduce riscv generic ABI - what I'm asking about here.
struct stat{,fs} layout for aarch64/ilp32 is going to be the new
standard for 32-bit ports, so I think we'd end up with 1 or 3, and
that's what Joseph tells about, if I understand him right.
> Joseph or Andreas can probably say which of those ways for handling
> this in aarch64 specific code is better (override bits/stat.h or
> convert the structure), and we can also go back to approach b)
> above (using the 32-bit ARM compatible structure) if that ends
> up being simpler.
>
> Arnd