From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7795 Path: news.gmane.org!not-for-mail From: Arnd Bergmann Newsgroups: gmane.linux.kernel.api,gmane.comp.lib.glibc.alpha,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 22:19:52 +0200 Message-ID: <2268301.gQGnhXiZzi@wuerfel> References: <2664016.bYZKg6FQqR@wuerfel> <5565E2AC.3070306@zytor.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1432758014 6328 80.91.229.3 (27 May 2015 20:20:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 20:20:14 +0000 (UTC) Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, klibc-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org, y2038-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rich Felker , cferris-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, enh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, "Joseph S. Myers" To: "H. Peter Anvin" Original-X-From: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Wed May 27 22:20:06 2015 Return-path: Envelope-to: glka-linux-api-wOFGN7rlS/M9smdsby/KFg@public.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yxho5-0005Q7-B9 for glka-linux-api-wOFGN7rlS/M9smdsby/KFg@public.gmane.org; Wed, 27 May 2015 22:20:05 +0200 Original-Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand id S1751766AbbE0UUE (ORCPT ); Wed, 27 May 2015 16:20:04 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.131]:63128 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751741AbbE0UUC (ORCPT ); Wed, 27 May 2015 16:20:02 -0400 Original-Received: from wuerfel.localnet ([149.172.15.242]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0Mex5B-1Yn4oG10xN-00OYPc; Wed, 27 May 2015 22:19:57 +0200 User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5565E2AC.3070306-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> X-Provags-ID: V03:K0:yzU9BJcti7BPvJ4Lg3ja6GmRWHzWz7N9rZjIGG6e2Qdxxy6gjBJ 088Evsa6VobdiTN0/NMV+9FBlSlKfT0m0tCzBCxvnN4lkXcz2QYr4Xsk+TVXEXRVpk7G5kt 0nL2YZ683lyAheFlyWhGuAGF9iQogU9wLzvyyymRyLxJ4TfbLsMLMdETldD8ofzzNNo3KD3 yIIotBf4cPXTRT4UDVszw== X-UI-Out-Filterresults: notjunk:1;V01:K0:HcSBVOAo0rI=:EW1e+7NDpUaLzSI+KvGz43 qvBfy3NGxzLOKMBX1mi/crZZXcK5dBUZ3/TTL7pEjdDUigecrjVzBc5f4i0KBUWewHeBql0ok Jbfd5GqG019k+UyWUMNwikzfxNG+fTMzG4iYeEIaz/HSqXsRGw1LfZ7ugqf4+cf3z3TFwhDee Zhb+mxeFj+49IhVNY4D+hqZL8lQ3/SOQ7AYiY9Nnj81d4vxfNAwBZbMjjFf/r2eNT9+YSfPN9 hyhzDHc5HouC9yLH5KGLKWLt+zqt6ELmiQWkOoGKVhBTbDWgXsVZRl82nazTP4EckLQS4NwdK zsSdKHBrVW/haeNAXOWrvjXGgT/NxHcyf1ZO2RcRuTrlJm81Ac/9bGmnuGdOrFYYb1c4QYp/o BrfCpXq23TOOA9XDctouNnl5MsmPI/YKoxmtRup4/cNZf+DexZTibT6yhEH1V3+X4S6cOgsvA 0xL6giEeFikIzx/6PkJ2yvUXJ+bUc4i5IZYFvBUoAd70VMYEYWECaSdYsR+gWcQy/+cbpB8bh //5KtPK50FRkN07m9900sn5a5xmcjAZE8rjGG5WTcSoMztWgGKNh/okSkEfX4/Eq2OYxLnuvU v6z+3tI3IRGQX5NnY9eYRp87N4dCW7FTlr5zZ99s4quhzf11BefUtxdMwrY9YNCtnVt2++uYP Z2W11VbaNt9yPIRJHXpMZzCtuVWwgn11Qms4sBYnP5LZUng== Original-Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Precedence: bulk List-ID: X-Mailing-List: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Xref: news.gmane.org gmane.linux.kernel.api:11526 gmane.comp.lib.glibc.alpha:51678 gmane.linux.kernel.year-2038:340 gmane.linux.lib.musl.general:7795 gmane.linux.kernel:1963938 Archived-At: On Wednesday 27 May 2015 08:28:44 H. Peter Anvin wrote: > 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 tried to keep a) and b) similar, and change nothing other than the introduction of the extra __kernel_time64_t and __kernel_timespec here, for the case of __KERNEL_TIME_BITS == __BITS_PER_LONG, in order to minimize the risk of introducing regressions for existing libc builds against new kernel headers. Case c) is the only one that actually changes the existing definitions, which makes it different from both a) and b). > 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. Ok, good to know. If that works for all libc implementations, we could take a simpler approach and just define __old_kernel_timespec plus __kernel_timespec but not timespec (and respectively for the other structures) when __KERNEL_TIME_BITS == 64 is set, and leave the real user space definitions up to libc (which can then add the #defines or not if they want to). Arnd