This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove unused sysdeps/unix/{,sysv/}getdents.c
On Tue, 24 Apr 2012, Carlos O'Donell wrote:
> On Tue, Apr 24, 2012 at 10:07 AM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > It occurs to me that when removing sysdeps/unix/sysv/getdents.c, the
> > getdents entry in sysdeps/unix/sysv/syscalls.list should also be
> > removed, so I propose this revised patch version that removes that
> > entry as well as the two unused getdents.c files. ?Tested x86_64.
> >
> > 2012-04-24 ?Joseph Myers ?<joseph@codesourcery.com>
> >
> > ? ? ? ?* sysdeps/unix/getdents.c: Remove file.
> > ? ? ? ?* sysdeps/unix/sysv/getdents.c: Likewise.
> > ? ? ? ?* sysdeps/unix/sysv/syscalls.list (s_getdents): Remove.
>
> Under what conditions is this syscalls.list used?
It, and all of sysdeps/unix/sysv, is used only with the Linux kernel.
Various other syscalls in that syscalls.list are also in fact unused
because of C files in sysdeps/unix/sysv/linux/. I would propose, in
separate patches, to remove those that are unused and move any that are
genuinely used into sysdeps/unix/sysv/linux/syscalls.list. At that point,
sysdeps/unix/sysv/ would serve no purpose other than as a container for
the "linux" directory. If we don't want the churn of moving "linux" up a
level to reflect that the "sysv" directory is not itself useful in glibc
now, it might make sense to enhance the configure code that lists sysdeps
directories to detect such a case - a sysdeps directory that does nothing
other than contain other sysdeps directories - and automatically remove
the directory from the generated list of sysdeps directories so that
"make" has fewer rules to deal with and compilation command lines when
building and testing are shorter.
In a similar vein of avoiding unnecessary sysdeps directories I've posted
patches to avoid the sysdeps/unix/mman and sysdeps/unix/inet directories.
I think sysdeps/unix/common can also similarly be eliminated; that
motivated my question to Thomas in
<http://sourceware.org/ml/libc-alpha/2012-04/msg00840.html> about the
actual sysdeps ordering used on Hurd, as I'd like to confirm that Hurd
really does use sysdeps/unix/bsd/bsd4.4/bits/dirent.h before removing the
unix/common version of that header, and that it uses
sysdeps/unix/bsd/tcsendbrk.c before moving the unix/common version of that
file to sysdeps/unix/sysv/linux/ to join the other tc*.c used on Linux.
--
Joseph S. Myers
joseph@codesourcery.com