This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Y2038: provide kernel support indication
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Albert ARIBAUD (3ADEV)" <albert dot aribaud at 3adev dot fr>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 19 Sep 2018 13:03:21 +0000
- Subject: Re: [PATCH] Y2038: provide kernel support indication
- References: <20180919071303.26636-1-albert.aribaud@3adev.fr>
On Wed, 19 Sep 2018, Albert ARIBAUD (3ADEV) wrote:
> * New function __y2038_get_kernel_support() returns:
> * 0 if the underlying kernel does not support Y2038 at all
> * > 0 if the underlying kernel has some support for Y2038
> * < 0 if the underlying kernel support for Y2038 is broken
> * New function __y2038_set_kernel_support() allows indicating
> a kernel's Y2038 support (or support failure)
> * Default implementation (covering non-Linux kernels) always
> returns 0 (no support).
There should be an __ASSUME_* macro that kernel-features.h defines when
the minimum kernel version has the required feature. Calls to these APIs
need to become compile-time constants in that case, with the functions /
variables not existing in the glibc binaries at all.
> + GLIBC_2.29 {
> + __y2038_get_kernel_support;
> + __y2038_set_kernel_support;
> + }
I don't think these should be public interfaces (but if they were, the
patch would need to update all the ABI test baselines). If exported for
use by other glibc shared libraries, they should be exported at version
GLIBC_PRIVATE. (That does require they are never used in code in
*_nonshared.a because that may end up in users' programs / shared
libraries, but very little should go in *_nonshared.a.)
--
Joseph S. Myers
joseph@codesourcery.com