This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Unused sys/ucontext.h files
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 29 Jan 2014 01:09:25 +0000
- Subject: Re: Unused sys/ucontext.h files
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401220324460 dot 25161 at digraph dot polyomino dot org dot uk> <20140128224328 dot C579D74438 at topped-with-meat dot com>
(moving to libc-alpha)
On Tue, 28 Jan 2014, Roland McGrath wrote:
> In general, I am against removing files of this category just because
> they are not used by any current configuration. That is, files that are
> machine-specific and for a machine that has some configurations in
> current use, but are OS-independent. I put them in the same category as
> the stub files, most of which are not used by any configuration that can
> be built. Stubs of function implementations provide the outline of the
> API and a starting point for filling in actual implementations.
> Similarly, pure machine-specific files provide at least the basics of
> the machine-specific API that should make sense across all OS
> configurations of libc for that machine.
In the case of sys/ucontext.h, I don't think anything meaningfully
OS-independent is possible; the choice of interface here is inherently up
to the OS kernel. If two OSes for the same architecture used the same
layout by accident rather than deliberate policy to keep it in sync, I'd
think it logically best for them to use two copies of the file. If the
argument is about cases where there is no conventional underlying kernel
and so glibc is free to determine the interface, I'd think it's most
natural to leave deciding on an architecture default for such a case until
such a port is actually being added.
In other cases, actually the OS-dependent file that is used is more
generic, or at least as generic, as the OS-independent file, and should
replace it. For example, wordsize.h and endian.h files (where
Linux-specific files allow for configurations supporting both 32-bit and
64-bit compilation and multiple endiannesses, but the OS-independent files
may assume one particular case), or sysdeps/sparc/sparc32/bits/setjmp.h.
(I intend to unify the MIPS bits/endian.h files on that basis ... actually
both are generic, but the sysdeps/mips/bits/endian.h version has an
incorrect comment claiming it's specific to big-endian.)
In general, certain things cause problems for global cleanups and for
build bots trying to ensure better automatic build coverage of different
glibc configurations (Jan-Benedict Glaw seems willing in #gcc discussion
to add some glibc coverage to his toolchain build bot):
* Files that are not used by any configuration (no good way to tell
whether to make some cleanup to them, or to test such a cleanup, or to
tell what the requirements on such a cleanup are).
* Configurations that do not build, with unmodified sources and unmodified
upstream tools (GCC, binutils, Linux kernel headers etc.).
* Configurations where what people actually use is significantly different
from the sources checked in to the glibc repository.
* Files and ports out of date with respect to global changes, as
enumerated at <https://sourceware.org/glibc/wiki/PortStatus> (you can
easily find a cleanup you want to make interacts with an area where a
previous cleanup is still missing from one port).
So, for the first of these issues I start from a position that the
"generic" nature of a particular file, along with it actually representing
the current desired glibc API rather than something older and not updated,
needs examining and justifying in any given case that can be identified.
And for the other three issues I think it at least very unfortunate that
hppa and Hurd have got into states of such divergence, and we need to
consider how to get them out of those states without the problems dragging
on indefinitely as they have done so far.
--
Joseph S. Myers
joseph@codesourcery.com