From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84679 invoked by alias); 8 Sep 2017 18:16:29 -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 84670 invoked by uid 89); 8 Sep 2017 18:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,URIBL_RED autolearn=no version=3.3.2 spammy=Hx-languages-length:1602 X-HELO: smtp6-g21.free.fr Date: Fri, 08 Sep 2017 18:16:00 -0000 From: Albert ARIBAUD To: Joseph Myers Cc: Zack Weinberg , GNU C Library Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof Message-ID: <20170908201619.465012b5.albert.aribaud@3adev.fr> In-Reply-To: References: <20170907224219.12483-1-albert.aribaud@3adev.fr> <20170908194154.49d5c670.albert.aribaud@3adev.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00398.txt.bz2 On Fri, 8 Sep 2017 17:59:00 +0000, Joseph Myers wrote : > 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.) Understood -- but as soon as 64-bit-time types are frozen on the kernel side, we could freeze the corresponding GLIBC API types (hopefully without a translation layer needed) and then if GLIBC gets out there before the kernel does, it won't be a problem since in any case the 64-bit-time implementation must fall back to 32-bit syscalls if the 64-bit syscalls return an ENOSYS. Cordialement, Albert ARIBAUD 3ADEV