From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752928AbbE0P3X (ORCPT ); Wed, 27 May 2015 11:29:23 -0400 Received: from terminus.zytor.com ([198.137.202.10]:37234 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344AbbE0P3V (ORCPT ); Wed, 27 May 2015 11:29:21 -0400 Message-ID: <5565E2AC.3070306@zytor.com> Date: Wed, 27 May 2015 08:28:44 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Arnd Bergmann , linux-api@vger.kernel.org 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" Subject: Re: [klibc] kernel/libc uapi changes for y2038 References: <2664016.bYZKg6FQqR@wuerfel> In-Reply-To: <2664016.bYZKg6FQqR@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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