This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: consolidate rename()
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Yury Norov <ynorov at caviumnetworks dot com>, Andreas Schwab <schwab at linux-m68k dot org>, GNU C Library <libc-alpha at sourceware dot org>, James Hogan <james dot hogan at imgtec dot com>, Arnd Bergmann <arnd at arndb dot de>
- Date: Sun, 16 Oct 2016 13:47:14 +0000
- Subject: Re: [PATCH] Linux: consolidate rename()
- Authentication-results: sourceware.org; auth=none
- References: <1476525379-2949-1-git-send-email-ynorov@caviumnetworks.com> <87vawtsr30.fsf@linux-m68k.org> <20161015145503.GA5158@yury-N73SV> <CAKCAbMjOy0EnNvu0suSi2zewkavy4Q-L7+DjGk=8kMgfnVQOyQ@mail.gmail.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