This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Merging some linux/generic code into linux?
- From: Chris Metcalf <cmetcalf at ezchip dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Mon, 4 Jan 2016 15:00:03 -0500
- Subject: Re: Merging some linux/generic code into linux?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp dot mailfrom=cmetcalf at ezchip dot com;
- References: <20151230234608 dot GA3839 at aurel32 dot net>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 12/30/2015 06:46 PM, Aurelien Jarno wrote:
Hi,
Now that the GNU libc requires at least a 2.6.32 kernel, the *at
syscalls are always available. This might gives the opportunity to
cleanup a bit the sysdeps/univ/sysv/linux/generic directory. In some
cases like dl-origin.c, the code is almost duplicated, differing only
by the syscall and its arguments. In some other cases like chown or
rename we have an entry in syscalls.list on one side, and a C file on
the other.
Do we want to keep things like that? Do we want to try merging
linux/generic and linux by using the *at version of the syscall for all
architectures? I am not sure if passing one more argument to the
syscalls really changes the performances.
Aurelien
This certainly seems like a nice maintainability cleanup from my
point of view. The obvious concern is (a bit of) performance, but
even that is likely canceled out once you get into the kernel.
Since the internal kernel do_sys_open() function called by sys_open()
and sys_openat() already requires the "dfd" argument, we pay a cost
in sys_open() to load up the AT_FDCWD value and re-marshal the
arguments to call do_sys_open(). For example, the x86_64 kernel
code has three more instructions for sys_open() than for sys_openat().
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com