This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Change __ASSUME_ACCEPT4 on powerpc to 2.6.37
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Adam Conrad <adconrad at 0c3 dot net>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 4 Jun 2013 19:58:07 +0000
- Subject: Re: [PATCH] Change __ASSUME_ACCEPT4 on powerpc to 2.6.37
- References: <20130604124225 dot GQ4389 at 0c3 dot net>
On Tue, 4 Jun 2013, Adam Conrad wrote:
> In Debian, we currently build with a minimum kernel version of 2.6.32
> for backward compat with squeeze, lucid, and RHEL6. __ASSUME_ACCEPT4
> is enabled for kernel versions >= 2.6.28 on x86, sparc, powerpc, and
> s390, however this wasn't actually exported on powerpc until 2.6.37ish
> in commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6:
This bug should be filed in Bugzilla as it looks like something that would
have been a user-visible bug in a release. (Whereas cases where an
__ASSUME_* macro isn't defined but could be are simply missing
optimizations, so don't need bugs filed when fixing them.)
Really we could do with a proper review of all the Linux kernel versions
used in kernel-features.h files, both in libc and ports, to assess whether
each macro is defined for the correct set of versions for all
architectures (to find both cases like this where the macro is defined for
too early a version, and also cases where a port should now define the
macro for some versions, but doesn't define it at all, and the main
kernel-features.h defines it only for a limited set of libc
architectures) - I very much doubt this is the only such bug.
That would be quite a substantial project ... maybe there should be a wiki
list of __ASSUME_* macros where people can check them off after verifying
that a single macro is defined for the correct versions, taking into
account all released kernels up to 3.9 (modulo ambiguity about whether to
use version N or N+1 when support was added in N-rcM) for all
architectures. It would be nice if such a list recorded cases where an
architecture didn't have the relevant feature as of 3.9 but might get it
in future, so we know what to watch out for regarding updating
kernel-features.h for new kernel releases in future.
--
Joseph S. Myers
joseph@codesourcery.com