From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5763 invoked by alias); 8 Sep 2017 17:59:11 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 5748 invoked by uid 89); 8 Sep 2017 17:59:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Fri, 08 Sep 2017 17:59:00 -0000 From: Joseph Myers To: Albert ARIBAUD CC: Zack Weinberg , GNU C Library Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof In-Reply-To: <20170908194154.49d5c670.albert.aribaud@3adev.fr> Message-ID: References: <20170907224219.12483-1-albert.aribaud@3adev.fr> <20170908194154.49d5c670.albert.aribaud@3adev.fr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-09/txt/msg00397.txt.bz2 On Fri, 8 Sep 2017, Albert ARIBAUD wrote: > Regarding whether the patches should land only once the kernel is > Y0238-safe: these patches are intended to run even on a current and thus > completely Y2038-unsafe kernel, in which case they use 64-bit-time on > user side (to make applications compiled with _TIME_BITS==64 happy at > least until Y2038 happens) and 32-bit time on kernel side. So I don't > see why these patches should wait for a Y2038-safe kernel per se. Where the kernel layouts of structures are suitable for use by glibc, we'd like to avoid translation layers. E.g., we need to know what the kernel's struct stat64 variant for 64-bit time_t will look like to ensure no translation layer is needed. (If the answer is that statx is the interface that should be used for 64-bit times in struct stat so the kernel doesn't need to define such a stat64 variant, then the translation layer is needed anyway and we should maybe use the asm-generic 64-bit struct stat variant of the layout on all 32-bit platforms.) -- Joseph S. Myers joseph@codesourcery.com