This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Remove pre-2.4.21 Linux kernel support
On Fri, 13 Jul 2012, Andreas Schwab wrote:
> All 64-bit architectures use the wordsize-64 variants which do not
> depend on __ASSUME_FCNTL64, __ASSUME_STAT64_SYSCALL or
> __ASSUME_MMAP2_SYSCALL, so these macros can be removed.
MIPS n64 does not use sysdeps/unix/sysv/linux/wordsize-64.
__ASSUME_STAT64_SYSCALL is defined for sparc64 but only for 2.6.12 and
later.
None of those macros is defined for S390.
Determining whether a macro can be removed requires a careful analysis of
all libc and ports architectures, to show for each that either (a) the
macro is always defined there, (b) no code testing the macro is used there
or (c) although not defined, it could in fact have been safely defined for
that architecture for the least supported kernel version - i.e., all the
code conditioned on the macro, that is used on the architecture, is safe
there for any supported kernel. Furthermore, it's necessary in some cases
to check for C function implementations that test the macros being
#included for other architectures rather than just used directly through
sysdeps search paths. It's necessary to be extremely careful with any
generalisations such as the above.
So I think the removal of such macros is best done in a separate patch for
each macro, that includes an extended rationale going through all the libc
and ports architectures and explaining why the change is OK for them all.
It's not enough to have done the analysis, it's necessary to explain it so
that, for each architecture, it's transparent from the given patch
rationale why the change is OK for that architecture.
<http://sourceware.org/ml/libc-alpha/2012-05/msg01842.html> is an example
illustrating the analysis required, in the case of
__ASSUME_TRUNCATE64_SYSCALL.
<http://sourceware.org/ml/libc-alpha/2012-05/msg01811.html> illustrates it
for __ASSUME_NEW_GETRLIMIT_SYSCALL, a case where files for one
architecture did get #included for others.
--
Joseph S. Myers
joseph@codesourcery.com