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: Chung-Lin Tang <cltang at codesourcery dot com>
- To: "Joseph S. Myers" <joseph 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: Fri, 18 Jul 2014 00:28:08 +0800
- 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> <Pine dot LNX dot 4 dot 64 dot 1407171412501 dot 8993 at digraph dot polyomino dot org dot uk>
On 2014/7/17 äå 10:19, Joseph S. Myers wrote:
> 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.
There's another review of the nios2 kernel port in progress, which
should cover this.
>> 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).
Yes, the original intention seemed to be for the renameat syscall to be
removed by default in 3.16, leaving only renameat2, unless
__ARCH_WANT_RENAMEAT is defined in the kernel port's
include/asm/unistd.h (which would be all current ports) That has not
happened yet; things seem still the same as 3.15 ATM.
If renameat is removed, and only renameat2 available, we need a
__ASSUME_RENAMEAT2 code path to support that, so I think this is sort of
independent from whether we provide a renameat2() API or not.
Anyways, we'll need a bit more clarification on what exactly will enter
3.16.
Chung-Lin
> 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).
>