From: "H. Peter Anvin" <hpa@zytor.com>
To: Arnd Bergmann <arnd@arndb.de>, 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 <dalias@libc.org>,
cferris@google.com, enh@google.com,
"Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: [klibc] kernel/libc uapi changes for y2038
Date: Wed, 27 May 2015 08:28:44 -0700 [thread overview]
Message-ID: <5565E2AC.3070306@zytor.com> (raw)
In-Reply-To: <2664016.bYZKg6FQqR@wuerfel>
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
next prev parent reply other threads:[~2015-05-27 15:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 9:53 Arnd Bergmann
2015-05-18 12:16 ` [klibc] " Thorsten Glaser
2015-05-18 13:32 ` [Y2038] " Arnd Bergmann
2015-05-18 17:03 ` Thorsten Glaser
2015-05-18 20:35 ` Arnd Bergmann
2015-05-19 17:54 ` [Y2038] " John Stultz
2015-05-27 15:28 ` H. Peter Anvin [this message]
[not found] ` <5565E2AC.3070306-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2015-05-27 20:19 ` [klibc] " Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5565E2AC.3070306@zytor.com \
--to=hpa@zytor.com \
--cc=arnd@arndb.de \
--cc=cferris@google.com \
--cc=dalias@libc.org \
--cc=enh@google.com \
--cc=joseph@codesourcery.com \
--cc=klibc@zytor.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=musl@lists.openwall.com \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).