This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Linux kernel version support policy
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: <libc-alpha at sourceware dot org>, Aurelien Jarno <aurel32 at debian dot org>
- Date: Tue, 28 Jan 2014 02:15:03 +0000
- Subject: Re: Linux kernel version support policy
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401272237400 dot 14736 at digraph dot polyomino dot org dot uk> <3591302 dot 5mrdmfoV2Y at vapier> <Pine dot LNX dot 4 dot 64 dot 1401280049050 dot 14736 at digraph dot polyomino dot org dot uk> <1578206 dot CTcFI8tkNA at vapier>
On Mon, 27 Jan 2014, Mike Frysinger wrote:
> i'm not saying the changes to actually remove support has to be written first.
> i'm saying we should have an idea of what conditionals would get cleaned up
> and how many files/LoC are actually impacted.
Well, supposing 2.6.32 were the version used, in the generic Linux
kernel-features.h this appears to affect __ASSUME_UTIMES,
__ASSUME_PSELECT, __ASSUME_PPOLL, __ASSUME_ATFCTS,
__ASSUME_SET_ROBUST_LIST, __ASSUME_COMPLETE_READV_WRITEV,
__ASSUME_FUTEX_LOCK_PI, __ASSUME_UTIMENSAT, __ASSUME_PRIVATE_FUTEX,
__ASSUME_FALLOCATE, __ASSUME_O_CLOEXEC, __ASSUME_ARG_MAX_STACK_BASED,
__ASSUME_ADJ_OFFSET_SS_READ, __ASSUME_SOCK_CLOEXEC, __ASSUME_IN_NONBLOCK,
__ASSUME_PIPE2, __ASSUME_EVENTFD2, __ASSUME_SIGNALFD4, __ASSUME_DUP3,
__ASSUME_ACCEPT4, __ASSUME_FUTEX_CLOCK_REALTIME, __ASSUME_AT_RANDOM,
__ASSUME_PREADV, __ASSUME_PWRITEV, __ASSUME_REQUEUE_PI,
__ASSUME_F_GETOWN_EX and __ASSUME_XFS_RESTRICTED_CHOWN. I haven't checked
what code is conditioned by these (and in some cases it's not
Linux-specific code, in which case conditionals can't be removed
completely unless Hurd also supports the feature, or the macros would
still only be defined for some architectures), but for example there's a
bug report about the pselect fallback which could be closed if that
fallback could go away (unfortunately, it appears it wasn't added until
3.0 for m68k), and loads of code conditional on __ASSUME_ATFCTS (where the
fallbacks allocate an arbitrary-size buffer with alloca, meaning stack
overflow for huge filenames, and use snprintf with non-obvious
consequences for signal-safety - could those uses of snprintf use
malloc?).
--
Joseph S. Myers
joseph@codesourcery.com