From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93697 invoked by alias); 8 Sep 2017 18:36:12 -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 93675 invoked by uid 89); 8 Sep 2017 18:36:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy= X-HELO: mailbackend.panix.com X-Gm-Message-State: AHPjjUg1CfHEV/1Lkc2B7BzjBmkm4j2feFspGP/9vrccyKi6kusRCK/9 BiHmF2fKpNwyMcMO8ZmWxFzDH5Ea2w== X-Google-Smtp-Source: AOwi7QDr8opRcfWeUkzHSpv6zH2ILp8M3mYxXx2z6uwJ1pPmkPGvvylhjPjqAGJ1irORK4k+L6L2mebc052G2UVSXZI= X-Received: by 10.202.237.149 with SMTP id l143mr3531017oih.75.1504895768389; Fri, 08 Sep 2017 11:36:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170908201619.465012b5.albert.aribaud@3adev.fr> References: <20170907224219.12483-1-albert.aribaud@3adev.fr> <20170908194154.49d5c670.albert.aribaud@3adev.fr> <20170908201619.465012b5.albert.aribaud@3adev.fr> From: Zack Weinberg Date: Fri, 08 Sep 2017 18:36:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/52] Make GLIBC Y2038-proof To: Albert ARIBAUD Cc: Joseph Myers , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-09/txt/msg00400.txt.bz2 On Fri, Sep 8, 2017 at 2:16 PM, Albert ARIBAUD wrote: > 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. I think that's right. Syscalls we can add support for later, types are much more troublesome. zw