lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 May 2014 04:18:00 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	John Stultz <john.stultz@...aro.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LeyFoon Tan <lftan.linux@...il.com>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Thu, May 15, 2014 at 01:08:02PM +0200, Arnd Bergmann wrote:
> c) glibc may or may not provide a way for applications to use
>    the extended interfaces without a user space ABI break. My
>    impression so far is that this is going to be too hard and
>    it won't be done, but this is for the glibc developers to
>    determine.
>
> The important distinction here is between user space time_t
> (timeval, timespec) and __kernel_time_t. We probably need
> to make the user space time_t a build-time conditional,
> at least for the foreseeable future. New architectures or
> new C libraries can start out using 64-bit time_t unconditionally.

I don't think there is any point in introducing new kernel interfaces
without having a talk to the glibc folks and people that represent the
Linux community in the standard body (e.g. Eric Blake).

How about you start sending a first high-level proposal with libc-alpha,
linux-kernel, linux-api and Eric in the Cc list and we'll see how we
can come up with something that is actually usable to solve our users
Y2038 problem.  Without coordination we're just handing on the hot
potato.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ