From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>,
<ryan.arnold@gmail.com>
Subject: Re: Remove pre-2.4.21 Linux kernel support
Date: Fri, 13 Jul 2012 10:27:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1207131013430.4352@digraph.polyomino.org.uk> (raw)
In-Reply-To: <m2txxcul15.fsf@igel.home>
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
next prev parent reply other threads:[~2012-07-13 10:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 23:40 Joseph S. Myers
2012-07-13 8:24 ` Andreas Schwab
2012-07-13 10:27 ` Joseph S. Myers [this message]
2012-07-25 20:50 ` Ryan S. Arnold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1207131013430.4352@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
--cc=ryan.arnold@gmail.com \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).