This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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: 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


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