From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7794 Path: news.gmane.org!not-for-mail From: "H. Peter Anvin" Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel.api,gmane.linux.kernel.year-2038,gmane.linux.lib.musl.general,gmane.linux.kernel Subject: Re: [klibc] kernel/libc uapi changes for y2038 Date: Wed, 27 May 2015 08:28:44 -0700 Message-ID: <5565E2AC.3070306@zytor.com> References: <2664016.bYZKg6FQqR@wuerfel> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1432740590 25971 80.91.229.3 (27 May 2015 15:29:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 15:29:50 +0000 (UTC) Cc: klibc@zytor.com, libc-alpha@sourceware.org, y2038@lists.linaro.org, musl@lists.openwall.com, linux-kernel@vger.kernel.org, Rich Felker , cferris@google.com, enh@google.com, "Joseph S. Myers" To: Arnd Bergmann , linux-api@vger.kernel.org Original-X-From: libc-alpha-return-59383-glibc-alpha=m.gmane.org@sourceware.org Wed May 27 17:29:48 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YxdGp-0007Aq-71 for glibc-alpha@plane.gmane.org; Wed, 27 May 2015 17:29:27 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=DTUOgOpKv8kdJu10 KCLhJZnHX/m7AIJUy5qmyiBH3Jf5iQfPmYgDR6u3kEt1HhwtRxSdUWaTXl1jNnJR os/3Jmu5TD//TTf8mdBzx8TvV1uEBp/0AqlLSk8OSUr5G8yzKYOr+zx5j1Ss2+34 KBrqSvc840A0DSMCHkS+LUd5JFI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=default; bh=mvJSf/jcQkEcf+392KEaGn Tzrqw=; b=pFTCTlJrr57hrG/T4xYYR+mo5I0GqzZizegrADXnUFxwsaaYa5zQwG 6Cccb8RZhimOKgbfPeG3SRESGBun/4ad0arrX2FpqMgjQHLzTDzaNkLSC+2GvYSF dXf3Cd7ukp6E+VccsQGwQELH1+g18xYMzf7lC6bSt9LOXe3cqmKPs= Original-Received: (qmail 23830 invoked by alias); 27 May 2015 15:29:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 23817 invoked by uid 89); 27 May 2015 15:29:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail.zytor.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <2664016.bYZKg6FQqR@wuerfel> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:51671 gmane.linux.kernel.api:11517 gmane.linux.kernel.year-2038:338 gmane.linux.lib.musl.general:7794 gmane.linux.kernel:1963585 Archived-At: On 05/18/2015 02:53 AM, Arnd Bergmann wrote: > In the patch series I posted recently [1], I introduce new system calls to deal > with modified data structures, but left the question open on how these should > be best accessed from libc. The patches introduce a new __kernel_time64_t type > and based on that five new data structured: struct __kernel_timespec, > struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage, > and struct __kernel_timex. This works fine for the case when all libc > implementations provide their own definitions to user space, but not for > the simplest case (e.g. klibc) where the user-visible structures come directly > from the kernel uapi headers. > > I still don't know what model the various libc developers prefer, so here is > an alternative approach, as a patch on top of the previous series: > > Now, we rename the original structures to struct __old_kernel_*, and use a > macro to define either the __old_kernel_* or the __kernel_* structure name > to the name we actually want in user space, based on a __KERNEL_TIME_BITS > macro that can be set to either 32 or 64 for 32-bit architectures by > the libc. Depending on that macro, the compiler will either see one > of these combinations (for each of the five structures): > > a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32: > > struct timespec based on 32-bit __kernel_time_t > struct __kernel_timespec based on 64-bit __kernel_time64_t > > b) __BITS_PER_LONG == 64 && __KERNEL_TIME_BITS == 64: > > struct timespec based on 64-bit __kernel_time_t > struct __kernel_timespec based on 64-bit __kernel_time64_t > > c) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 64: > > struct __old_kernel_timespec based on 32-bit __kernel_time_t > struct timespec based on 64-bit __kernel_time64_t > > Would this work for everyone? Any alternative suggestions? > It seems to work, except I don't really understand why there is a difference between (b) and (c). I also have no problem just having klibc contain its own definitions of these structures, as long as one can prevent the kernel from defining them. -hpa