This is the mail archive of the 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] Add renameat2 function [BZ #17662]

On Mon, 2 Jul 2018, Yury Norov wrote:

> I think this function should look like this (not tested):
> int
> renameat2 (int oldfd, const char *old, int newfd, const char *new,
>            unsigned int flags)
> {
> # ifdef __NR_renameat2
>   return INLINE_SYSCALL_CALL (renameat2, oldfd, old, newfd, new, flags);
> # else
>   /* Try renameat if possible.  */

That's obviously wrong; it would mean that if you start building glibc 
with newer kernel headers, it would not support a fallback, on older 
kernels used at runtime, that is supported when building with older kernel 
headers.  It is always the case that building with newer kernel headers 
should not regress support for older kernels at runtime, and that if you 
have a fallback, it's __ASSUME_*, defined based on the --enable-kernel 
version, that is used to decide whether the fallback can be disabled.  
(Whether you should have a fallback at all is a case-by-case question 
depending on whether some or all cases of the API can be effectively 
emulated on older kernels.  But the starting point for any API, certainly 
any API that is added to the OS-independent GNU API, is that the semantics 
of that API may be implemented in any convenient way, not necessarily by 
calling a directly corresponding syscall.  See e.g. how all the *at 
functions originally had fallbacks using /proc until the minimum kernel 
version for glibc was recent enough to assume the syscalls to be present.)

Joseph S. Myers

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