This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove divide from _ELF_DYNAMIC_DO_RELOC
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>
- Cc: Chung-Lin Tang <chunglin_tang at mentor dot com>, Carlos O'Donell <carlos at redhat dot com>, <libc-alpha at sourceware dot org>, Allan McRae <allan at archlinux dot org>, David Miller <davem at davemloft dot net>, OndÅej BÃlka <neleai at seznam dot cz>
- Date: Thu, 17 Jul 2014 14:19:08 +0000
- Subject: Re: [PATCH] Remove divide from _ELF_DYNAMIC_DO_RELOC
- Authentication-results: sourceware.org; auth=none
- References: <5347B7EE dot 6020507 at mentor dot com> <537F542B dot 5040409 at redhat dot com> <53C4C1D5 dot 40002 at mentor dot com> <53C58F53 dot 8080506 at redhat dot com> <53C64736 dot 5090700 at mentor dot com> <Pine dot LNX dot 4 dot 64 dot 1407162141290 dot 22313 at digraph dot polyomino dot org dot uk> <53C7867D dot 3060409 at codesourcery dot com>
On Thu, 17 Jul 2014, Chung-Lin Tang wrote:
> > As for the rest, is there rough consensus in the Linux kernel community on
> > the kernel/userspace ABI for Nios II (in particular, the size of time_t,
> > but also other issues such as whether renameat will need implementing in
> > userspace in terms of the renameat2 syscall)? That's needed for it to be
> > safe to add the port to glibc.
>
> I don't see either of those patches in 3.16-rc5 at the moment, so I
> guess it won't be an issue for 3.16.
>
> I'm not sure about the time_t/timespec changes, but renameat2 should be
Well, that ABI needs sorting out - you need to get kernel community
consensus about time_t for Nios II - before it's safe to include the port.
> pretty straightforward, just a new __ASSUME_RENAMEAT2 in
> kernel-features.h for 3.16 (if it gets in later), and maybe adding
> renameat2() as an API function.
That's the wrong way round. There's no need for __ASSUME_RENAMEAT2 unless
either (a) it's added as an API function (regarding which, see
<https://sourceware.org/ml/libc-alpha/2014-06/msg00421.html>) and you want
a fallback version of that API function for older kernels, or (b) some
interface can be implemented with renameat2, or in a more complicated way
for kernels not supporting renameat2. There's no apparent value in
implementing the rename and renameat APIs using renameat2 on existing
architectures, so no need for __ASSUME_RENAMEAT2 (rather, if Nios II gets
only the renameat2 syscall but not the renameat syscall, it and any
other asm-generic architectures added to the kernel in future would use
the renameat2 syscall to implement the rename and renameat APIs, while
AArch64, Tile and any other asm-generic architectures already supported in
the kernel but not glibc would continue to use the existing code
implementing those functions with the renameat syscall).
I suppose you might have a new __ASSUME_RENAMEAT_SYSCALL to be defined by
the subset of asm-generic architectures that have such a syscall (if the
direction is that new architectures don't have that syscall).
--
Joseph S. Myers
joseph@codesourcery.com