From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7704 Path: news.gmane.org!not-for-mail From: John Stultz 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: [Y2038] kernel/libc uapi changes for y2038 Date: Tue, 19 May 2015 10:54:45 -0700 Message-ID: References: <2664016.bYZKg6FQqR@wuerfel> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1432058114 3320 80.91.229.3 (19 May 2015 17:55:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 17:55:14 +0000 (UTC) Cc: Linux API , klibc@zytor.com, libc-alpha@sourceware.org, y2038 Mailman List , musl@lists.openwall.com, lkml , Rich Felker , cferris@google.com, Elliott Hughes , "Joseph S. Myers" To: Arnd Bergmann Original-X-From: libc-alpha-return-59028-glibc-alpha=m.gmane.org@sourceware.org Tue May 19 19:55:09 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 1YuljD-0008D1-C6 for glibc-alpha@plane.gmane.org; Tue, 19 May 2015 19:54:55 +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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; q=dns; s=default; b= MClp4gCv4lBSFOBcU+7qQGn7P04DncIHzDQ0qEER4Xgsc9RiEpytT4OqrmkX+fUn NeXi2fr80Wx52QU2p3PN8ygjlf9Ef4zDPAirCcM1hH9VtTDT4Ry4m90FxX+9lUgc 9c26Vncp9r8BpmAuEQnuPL+kyXW7+NQCEUnjTWKynX0= 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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; s=default; bh=bCDD9 Vy9SR4oiRjYlIRq3uNdHss=; b=r+RiK179ZPiJaAxOScMlx1SLZelx9nGBNrxSm d1FoFITZ5eICAbq5zu/r+vXGnUeTcw+dBIHH0zG4epG9BoCukdgeyjLSX111MwGF h6EE1KHhvnoxLUsjz4Tjb/e1oXuFjxaV8pkaHd8ThL4YK0Oq4dIgzasjW/KbUxPZ UCpumk= Original-Received: (qmail 73849 invoked by alias); 19 May 2015 17:54:50 -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 73837 invoked by uid 89); 19 May 2015 17:54:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f171.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W3lsD3DTZR2q/97RC/DPlA7R4GpNzxc94448kU0UKRs=; b=kiFKWGahJqvqdnK5A9m3Bc5Z1CfgxniItGbuJtF3TLyYW4WTPIKcZQ9gfhxtrsLrAw BTGwiA3tyh3pzAnFJRus7fW6TvfucWJutXzj9LUaTxcEiSy9SB+P4moNLa301GkBOzUn reR7UTAIHVWMUYrAYBfdPMyksRAU3tvufJsLv81F4zio6s+qwjPgGciHfCqPgYvN+DYk yRVvFkMnmv4skHz7Qb9+hoSN2AiLBRIUda1yJ1PBMZclyIzYvotER75tc28BAHciLcxL WB+wv3zwjB7vvu8CutQlver0rHtmHJScLM8GzA+6g4oTOOlBhDG3sEa1w6cuM9hITyzb HLtw== X-Gm-Message-State: ALoCoQnBxWov6Po9FLx+3b5zV3zPXOHAKxnD055aQkPJjwMd8I5ejpRfU8QqAeahdKiEuOaAygP+ X-Received: by 10.107.11.211 with SMTP id 80mr37684317iol.18.1432058085534; Tue, 19 May 2015 10:54:45 -0700 (PDT) In-Reply-To: <2664016.bYZKg6FQqR@wuerfel> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:51316 gmane.linux.kernel.api:11315 gmane.linux.kernel.year-2038:276 gmane.linux.lib.musl.general:7704 gmane.linux.kernel:1957560 Archived-At: On Mon, May 18, 2015 at 2: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? > > Arnd > > [1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls > https://lwn.net/Articles/643407/ > > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h > index 23e6c416b85f..ecdaf4f77f35 100644 > --- a/include/uapi/asm-generic/bitsperlong.h > +++ b/include/uapi/asm-generic/bitsperlong.h > @@ -12,4 +12,13 @@ > #define __BITS_PER_LONG 32 > #endif > > +/* > + * Traditionally we define defines 'time_t' as 'long', but we need to > + * migrate to a 64-bit type until 2038. This one is designed to be > + * overridden by user space if it's prepared to handle 64-bit time_t. > + */ > +#ifndef __KERNEL_TIME_BITS > +#define __KERNEL_TIME_BITS __BITS_PER_LONG > +#endif > + > #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */ > diff --git a/include/uapi/asm-generic/kernel_stat.h b/include/uapi/asm-generic/kernel_stat.h > index d1db22583046..3693496c78aa 100644 > --- a/include/uapi/asm-generic/kernel_stat.h > +++ b/include/uapi/asm-generic/kernel_stat.h > @@ -1,6 +1,14 @@ > #ifndef __ASM_GENERIC_KERNEL_STAT_H > #define __ASM_GENERIC_KERNEL_STAT_H > > +#include > + > +#if __KERNEL_TIME_BITS == 32 || __BITS_PER_LONG == 64 > +#define __old_kernel_stat2 stat > +#else > +#define __kernel_stat stat > +#endif > + > /* > * The new structure that works on both 32-bit and 64-bit and survives y2038 > * The layout matches 'struct stat' from asm-generic/stat.h on 64-bit > diff --git a/include/uapi/asm-generic/stat.h b/include/uapi/asm-generic/stat.h > index 64c32ba7c1a9..f66b28b96c8d 100644 > --- a/include/uapi/asm-generic/stat.h > +++ b/include/uapi/asm-generic/stat.h > @@ -22,7 +22,7 @@ > > #define STAT_HAVE_NSEC 1 > > -struct stat { > +struct __old_kernel_stat2 { > unsigned long st_dev; /* Device. */ > unsigned long st_ino; /* File serial number. */ > unsigned int st_mode; /* File mode. */ > diff --git a/include/uapi/linux/resource.h b/include/uapi/linux/resource.h > index c4f3ba44db00..9a3876cc4436 100644 > --- a/include/uapi/linux/resource.h > +++ b/include/uapi/linux/resource.h > @@ -3,10 +3,16 @@ > > #include > #include > +#include > > /* > * Resource control/accounting header file for linux > */ > +#if __KERNEL_TIME_BITS == 32 || __BITS_PER_LONG == 64 > +#define __old_kernel_rusage rusage > +#else > +#define __kernel_rusage rusage > +#endif This all looks ok to me. Though I wonder if it would be cleaner to have all these conditional definitions in one header, rather then littered about in a ton of files. I'm torn because having the definitions close to the underlying structure helps folks reading through the code, but it still seems a little bit messy. thanks -john