This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unused sys/ucontext.h files


(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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]