linux-kernel - Re: [PATCH 01/25] asm-generic: Change time_t and clock

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 May 2014 15:38:51 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	James Hogan <james.hogan@...tec.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit

On Tuesday 13 May 2014 15:11:33 Geert Uytterhoeven wrote:
> On Tue, May 13, 2014 at 2:07 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Tue, 13 May 2014, Arnd Bergmann wrote:
> >> On Tuesday 13 May 2014 18:17:40 Ley Foon Tan wrote:
> >> > When we export this posix_types.h file for user software, they need to
> >> > define this config, eg: CONFIG_32BIT_TIME to use 32 bit time. Is this
> >> > what we want to do?
> >>
> >> No, this doesn't really work: You can't use CONFIG_* symbols in
> >> user-visible header files.
> >
> > Then make the config symbol generate the header from a template.
> 
> Indeed. I think it's worthwhile to add CONFIG_* expansion for such "hard"
> CONFIG symbols to make headers_install, cfr. the existing unifdef support.
> 
> We do such a hard work to improve asm-generic, so new architectures can
> just use that, only to see early adaptors now having to migrate away from it
> (e.g. OpenRISC suddenly gaining uapi/asm/posix_types.h).

This was always the idea: New architectures should use the default ABI
as it is defined at the time when they get added. When we later change
the ABI, everything that is already there is no longer using the default,
so they now have to change.
 
> Or is there another solution?

We could in theory have a versioned ABI, and define for instance that
openrisc uses the 3.1 version while nios2 uses the 3.16 version.

Doing that would introduce other problems I guess, but it would
avoid the use of changing lots of architectures when the default
ABI changes.

	Arnd
--
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/