Re: [PATCH] Linux: consolidate rename()

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 15 Oct 2016, Zack Weinberg wrote:

> with an appropriate conditional definition of __ASSUME_RENAMEAT2 added
> to kernel-features.h.  (renameat2 appears to have been added in 3.15,
> which I *think* corresponds to __LINUX_KERNEL_VERSION >= 0x030f00.)

And it's necessary when adding such definitions to check the kernel for 
*all* architectures supported by glibc, to make sure the syscall is 
present in both asm/unistd.h and the syscall table on all such 
architectures, since sometimes a syscall is not added for all 
architectures at the same time, or isn't added to both the syscall table 
and unistd.h at the same time.

The minimal conservative patch to handle architectures with only renameat2 
is to make sysdeps/unix/sysv/linux/generic/rename.c use renameat if 
__NR_renameat is used, otherwise use renameat2 - *and* to add 
sysdeps/unix/sysv/linux/generic/renameat.c to implement renameat in terms 
of the renameat2 syscall.

There is no need to change which syscalls are used for architectures where 
rename / renameat syscalls are available - thus, if you propose to do so, 
such a proposal would best be separated from fixing the case of 
architectures with only renameat2, and given its own self-contained 
rationale.  In my view, the complexity of runtime tests for the renameat2 
syscall is unjustified; implementing rename or renameat in terms of the 
renameat2 syscall on architectures with rename or renameat syscalls should 
not be considered until the minimum supported kernel for those 
architectures is one in which the renameat2 syscall is available.

-- 
Joseph S. Myers
joseph@codesourcery.com