This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove divide from _ELF_DYNAMIC_DO_RELOC


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).
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]