* [PATCH 00/25] Change time_t and clock_t to 64 bit
@ 2014-05-13 8:57 Ley Foon Tan
2014-05-13 9:02 ` [PATCH 01/25] asm-generic: " Ley Foon Tan
` (25 more replies)
0 siblings, 26 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 8:57 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, Arnd Bergmann
This patchset change default time_t and clock_t to 64 bit in
include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
these define to 32 bit in arch posix_types.h.
There is request to support 64 bit time_t for new architecture [1]. According to the
previous discussion we had (in [2]), defining suseconds_t as 64-bit, while probably
reasonable for LP64 or LP64+ILP32 architectures, but can makes things troublesome
for ILP32 architectures, not to mention the additional overhead.
This series is compiled tested on ARM, mips, powerpc32 and x86_64, but only boot
tested on ARM.
These patches are also available on this branch:
git://git.rocketboards.org/linux-socfpga-next.git 64bit_time
[1] https://lkml.org/lkml/2012/11/14/358
[2] https://lkml.org/lkml/2014/4/18/216
Ley Foon Tan (25):
asm-generic: Change time_t and clock_t to 64 bit
arc: Add 32 bit time_t and clock_t
arm: Add 32 bit time_t and clock_t
avr32: Add 32 bit time_t and clock_t
blackfin: Add 32 bit time_t and clock_t
c6x: Add 32 bit time_t and clock_t
cris: Add 32 bit time_t and clock_t
frv: Add 32 bit time_t and clock_t
hexagon: Add 32 bit time_t and clock_t
m32r: Add 32 bit time_t and clock_t
m68k: Add 32 bit time_t and clock_t
metag: Add 32 bit time_t and clock_t
microblaze: Add 32 bit time_t and clock_t
mips: Add 32 bit time_t and clock_t
mn10300: Add 32 bit time_t and clock_t
openrisc: Add 32 bit time_t and clock_t
parisc: Add 32 bit time_t and clock_t
powerpc: Add 32 bit time_t and clock_t
s390: Add 32 bit time_t and clock_t
score: Add 32 bit time_t and clock_t
sh: Add 32 bit time_t and clock_t
sparc: Add 32 bit time_t and clock_t
unicore32: Add 32 bit time_t and clock_t
x86: Add 32 bit time_t and clock_t
xtense: Add 32 bit time_t and clock_t
arch/arc/include/asm/Kbuild | 1 -
arch/arc/include/uapi/asm/Kbuild | 1 +
arch/arc/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/arm/include/uapi/asm/posix_types.h | 6 ++++++
arch/avr32/include/uapi/asm/posix_types.h | 6 ++++++
arch/blackfin/include/uapi/asm/posix_types.h | 6 ++++++
arch/c6x/include/asm/Kbuild | 1 -
arch/c6x/include/uapi/asm/Kbuild | 1 +
arch/c6x/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/cris/include/uapi/asm/posix_types.h | 6 ++++++
arch/frv/include/uapi/asm/posix_types.h | 6 ++++++
arch/hexagon/include/asm/Kbuild | 1 -
arch/hexagon/include/uapi/asm/Kbuild | 1 +
arch/hexagon/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/m32r/include/uapi/asm/posix_types.h | 6 ++++++
arch/m68k/include/uapi/asm/posix_types.h | 6 ++++++
arch/metag/include/asm/Kbuild | 1 -
arch/metag/include/uapi/asm/Kbuild | 1 +
arch/metag/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/microblaze/include/uapi/asm/posix_types.h | 6 ++++++
arch/mips/include/uapi/asm/posix_types.h | 6 ++++++
arch/mn10300/include/uapi/asm/posix_types.h | 6 ++++++
arch/openrisc/include/asm/Kbuild | 1 -
arch/openrisc/include/uapi/asm/Kbuild | 1 +
arch/openrisc/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/parisc/include/uapi/asm/posix_types.h | 8 ++++++++
arch/powerpc/include/uapi/asm/posix_types.h | 6 ++++++
arch/s390/include/uapi/asm/posix_types.h | 6 ++++++
arch/score/include/uapi/asm/posix_types.h | 6 ++++++
arch/sh/include/uapi/asm/posix_types_32.h | 6 ++++++
arch/sparc/include/uapi/asm/posix_types.h | 6 ++++++
arch/unicore32/include/asm/Kbuild | 1 -
arch/unicore32/include/uapi/asm/Kbuild | 1 +
arch/unicore32/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
arch/x86/include/uapi/asm/posix_types_32.h | 6 ++++++
arch/xtensa/include/uapi/asm/posix_types.h | 6 ++++++
include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
37 files changed, 230 insertions(+), 8 deletions(-)
create mode 100644 arch/arc/include/uapi/asm/posix_types.h
create mode 100644 arch/c6x/include/uapi/asm/posix_types.h
create mode 100644 arch/hexagon/include/uapi/asm/posix_types.h
create mode 100644 arch/metag/include/uapi/asm/posix_types.h
create mode 100644 arch/openrisc/include/uapi/asm/posix_types.h
create mode 100644 arch/unicore32/include/uapi/asm/posix_types.h
--
1.8.2.1
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
@ 2014-05-13 9:02 ` Ley Foon Tan
2014-05-13 9:15 ` James Hogan
2014-05-13 9:02 ` [PATCH 02/25] arc: Add 32 bit time_t and clock_t Ley Foon Tan
` (24 subsequent siblings)
25 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:02 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, Arnd Bergmann
Use 64 bit time_t and clock_t as default. 32 bit users can provide
an override to define these as "long" if needed.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
index fe74fcc..3f0e613 100644
--- a/include/uapi/asm-generic/posix_types.h
+++ b/include/uapi/asm-generic/posix_types.h
@@ -81,12 +81,22 @@ typedef struct {
#endif
/*
+ * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
+ * define these as "long" if needed.
+ */
+#ifndef __kernel_time_t
+typedef long long __kernel_time_t;
+#endif
+
+#ifndef __kernel_clock_t
+typedef long long __kernel_clock_t;
+#endif
+
+/*
* anything below here should be completely generic
*/
typedef __kernel_long_t __kernel_off_t;
typedef long long __kernel_loff_t;
-typedef __kernel_long_t __kernel_time_t;
-typedef __kernel_long_t __kernel_clock_t;
typedef int __kernel_timer_t;
typedef int __kernel_clockid_t;
typedef char * __kernel_caddr_t;
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 02/25] arc: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
2014-05-13 9:02 ` [PATCH 01/25] asm-generic: " Ley Foon Tan
@ 2014-05-13 9:02 ` Ley Foon Tan
2014-05-13 9:02 ` [PATCH 03/25] arm: " Ley Foon Tan
` (23 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:02 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, Vineet Gupta
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/arc/include/asm/Kbuild | 1 -
arch/arc/include/uapi/asm/Kbuild | 1 +
arch/arc/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/arc/include/uapi/asm/posix_types.h
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index e76fd79..2186afc 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -30,7 +30,6 @@ generic-y += parport.h
generic-y += pci.h
generic-y += percpu.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += scatterlist.h
diff --git a/arch/arc/include/uapi/asm/Kbuild b/arch/arc/include/uapi/asm/Kbuild
index 18fefae..1d6ffba 100644
--- a/arch/arc/include/uapi/asm/Kbuild
+++ b/arch/arc/include/uapi/asm/Kbuild
@@ -5,6 +5,7 @@ header-y += page.h
header-y += setup.h
header-y += byteorder.h
header-y += cachectl.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += sigcontext.h
header-y += signal.h
diff --git a/arch/arc/include/uapi/asm/posix_types.h b/arch/arc/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..ac69105
--- /dev/null
+++ b/arch/arc/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_ARC_POSIX_TYPES_H
+#define __ARCH_ARC_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 03/25] arm: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
2014-05-13 9:02 ` [PATCH 01/25] asm-generic: " Ley Foon Tan
2014-05-13 9:02 ` [PATCH 02/25] arc: Add 32 bit time_t and clock_t Ley Foon Tan
@ 2014-05-13 9:02 ` Ley Foon Tan
2014-05-13 9:02 ` [PATCH 04/25] avr32: " Ley Foon Tan
` (22 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:02 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Russell King, linux-arm-kernel
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/arm/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/include/uapi/asm/posix_types.h b/arch/arm/include/uapi/asm/posix_types.h
index d2de9cb..2f8e30f 100644
--- a/arch/arm/include/uapi/asm/posix_types.h
+++ b/arch/arm/include/uapi/asm/posix_types.h
@@ -32,6 +32,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 04/25] avr32: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (2 preceding siblings ...)
2014-05-13 9:02 ` [PATCH 03/25] arm: " Ley Foon Tan
@ 2014-05-13 9:02 ` Ley Foon Tan
2014-05-13 20:19 ` Hans-Christian Egtvedt
2014-05-13 9:02 ` [PATCH 05/25] blackfin: " Ley Foon Tan
` (21 subsequent siblings)
25 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:02 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Haavard Skinnemoen,
Hans-Christian Egtvedt
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/avr32/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/avr32/include/uapi/asm/posix_types.h b/arch/avr32/include/uapi/asm/posix_types.h
index 5b813a8..47d5146 100644
--- a/arch/avr32/include/uapi/asm/posix_types.h
+++ b/arch/avr32/include/uapi/asm/posix_types.h
@@ -32,6 +32,12 @@ typedef unsigned short __kernel_old_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _UAPI__ASM_AVR32_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 05/25] blackfin: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (3 preceding siblings ...)
2014-05-13 9:02 ` [PATCH 04/25] avr32: " Ley Foon Tan
@ 2014-05-13 9:02 ` Ley Foon Tan
2014-05-13 9:03 ` [PATCH 06/25] c6x: " Ley Foon Tan
` (20 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:02 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Steven Miao, adi-buildroot-devel
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/blackfin/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/blackfin/include/uapi/asm/posix_types.h b/arch/blackfin/include/uapi/asm/posix_types.h
index 9608ef6..e005638 100644
--- a/arch/blackfin/include/uapi/asm/posix_types.h
+++ b/arch/blackfin/include/uapi/asm/posix_types.h
@@ -25,6 +25,12 @@ typedef unsigned short __kernel_old_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _UAPI__ARCH_BFIN_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 06/25] c6x: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (4 preceding siblings ...)
2014-05-13 9:02 ` [PATCH 05/25] blackfin: " Ley Foon Tan
@ 2014-05-13 9:03 ` Ley Foon Tan
2014-05-13 9:03 ` [PATCH 08/25] frv: " Ley Foon Tan
` (19 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:03 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Mark Salter,
Aurelien Jacquiot, linux-c6x-dev
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/c6x/include/asm/Kbuild | 1 -
arch/c6x/include/uapi/asm/Kbuild | 1 +
arch/c6x/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/c6x/include/uapi/asm/posix_types.h
diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild
index 8dbdce8..cf7bd2e 100644
--- a/arch/c6x/include/asm/Kbuild
+++ b/arch/c6x/include/asm/Kbuild
@@ -35,7 +35,6 @@ generic-y += pci.h
generic-y += percpu.h
generic-y += pgalloc.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += scatterlist.h
diff --git a/arch/c6x/include/uapi/asm/Kbuild b/arch/c6x/include/uapi/asm/Kbuild
index e9bc2b2..7435d6c 100644
--- a/arch/c6x/include/uapi/asm/Kbuild
+++ b/arch/c6x/include/uapi/asm/Kbuild
@@ -5,6 +5,7 @@ generic-y += kvm_para.h
header-y += byteorder.h
header-y += kvm_para.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += setup.h
header-y += sigcontext.h
diff --git a/arch/c6x/include/uapi/asm/posix_types.h b/arch/c6x/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..dbad459
--- /dev/null
+++ b/arch/c6x/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_C6X_POSIX_TYPES_H
+#define __ARCH_C6X_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 08/25] frv: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (5 preceding siblings ...)
2014-05-13 9:03 ` [PATCH 06/25] c6x: " Ley Foon Tan
@ 2014-05-13 9:03 ` Ley Foon Tan
2014-05-13 9:03 ` [PATCH 09/25] hexagon: " Ley Foon Tan
` (18 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:03 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, David Howells
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/frv/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/frv/include/uapi/asm/posix_types.h b/arch/frv/include/uapi/asm/posix_types.h
index fe512af..0a837e6 100644
--- a/arch/frv/include/uapi/asm/posix_types.h
+++ b/arch/frv/include/uapi/asm/posix_types.h
@@ -20,6 +20,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 09/25] hexagon: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (6 preceding siblings ...)
2014-05-13 9:03 ` [PATCH 08/25] frv: " Ley Foon Tan
@ 2014-05-13 9:03 ` Ley Foon Tan
2014-05-13 9:03 ` [PATCH 10/25] m32r: " Ley Foon Tan
` (17 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:03 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Richard Kuo, linux-hexagon
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/hexagon/include/asm/Kbuild | 1 -
arch/hexagon/include/uapi/asm/Kbuild | 1 +
arch/hexagon/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/hexagon/include/uapi/asm/posix_types.h
diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild
index 0e69796..fbceaf8 100644
--- a/arch/hexagon/include/asm/Kbuild
+++ b/arch/hexagon/include/asm/Kbuild
@@ -33,7 +33,6 @@ generic-y += msgbuf.h
generic-y += pci.h
generic-y += percpu.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += rwsem.h
diff --git a/arch/hexagon/include/uapi/asm/Kbuild b/arch/hexagon/include/uapi/asm/Kbuild
index c31706c..336a2d0 100644
--- a/arch/hexagon/include/uapi/asm/Kbuild
+++ b/arch/hexagon/include/uapi/asm/Kbuild
@@ -5,6 +5,7 @@ header-y += bitsperlong.h
header-y += byteorder.h
header-y += kvm_para.h
header-y += param.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += registers.h
header-y += setup.h
diff --git a/arch/hexagon/include/uapi/asm/posix_types.h b/arch/hexagon/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..01e6b1c
--- /dev/null
+++ b/arch/hexagon/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_HEXAGON_POSIX_TYPES_H
+#define __ARCH_HEXAGON_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 10/25] m32r: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (7 preceding siblings ...)
2014-05-13 9:03 ` [PATCH 09/25] hexagon: " Ley Foon Tan
@ 2014-05-13 9:03 ` Ley Foon Tan
2014-05-13 9:03 ` [PATCH 11/25] m68k: " Ley Foon Tan
` (16 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:03 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Hirokazu Takata, linux-m32r
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/m32r/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/m32r/include/uapi/asm/posix_types.h b/arch/m32r/include/uapi/asm/posix_types.h
index 236de26..77cf049 100644
--- a/arch/m32r/include/uapi/asm/posix_types.h
+++ b/arch/m32r/include/uapi/asm/posix_types.h
@@ -20,6 +20,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _ASM_M32R_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 11/25] m68k: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (8 preceding siblings ...)
2014-05-13 9:03 ` [PATCH 10/25] m32r: " Ley Foon Tan
@ 2014-05-13 9:03 ` Ley Foon Tan
2014-05-13 9:04 ` [PATCH 12/25] metag: " Ley Foon Tan
` (15 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:03 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Geert Uytterhoeven, linux-m68k
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/m68k/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/m68k/include/uapi/asm/posix_types.h b/arch/m68k/include/uapi/asm/posix_types.h
index cf4dbf7..01e39fe 100644
--- a/arch/m68k/include/uapi/asm/posix_types.h
+++ b/arch/m68k/include/uapi/asm/posix_types.h
@@ -20,6 +20,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 12/25] metag: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (9 preceding siblings ...)
2014-05-13 9:03 ` [PATCH 11/25] m68k: " Ley Foon Tan
@ 2014-05-13 9:04 ` Ley Foon Tan
2014-05-13 9:22 ` James Hogan
2014-05-13 9:05 ` [PATCH 13/25] microblaze: " Ley Foon Tan
` (14 subsequent siblings)
25 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:04 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, James Hogan, linux-metag
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/metag/include/asm/Kbuild | 1 -
arch/metag/include/uapi/asm/Kbuild | 1 +
arch/metag/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/metag/include/uapi/asm/posix_types.h
diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild
index c29ead8..5a97e0d6 100644
--- a/arch/metag/include/asm/Kbuild
+++ b/arch/metag/include/asm/Kbuild
@@ -31,7 +31,6 @@ generic-y += param.h
generic-y += pci.h
generic-y += percpu.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += scatterlist.h
generic-y += sections.h
diff --git a/arch/metag/include/uapi/asm/Kbuild b/arch/metag/include/uapi/asm/Kbuild
index 84e09fe..1542689 100644
--- a/arch/metag/include/uapi/asm/Kbuild
+++ b/arch/metag/include/uapi/asm/Kbuild
@@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
header-y += byteorder.h
header-y += ech.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += resource.h
header-y += sigcontext.h
diff --git a/arch/metag/include/uapi/asm/posix_types.h b/arch/metag/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..d643b22
--- /dev/null
+++ b/arch/metag/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_METAG_POSIX_TYPES_H
+#define __ARCH_METAG_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 13/25] microblaze: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (10 preceding siblings ...)
2014-05-13 9:04 ` [PATCH 12/25] metag: " Ley Foon Tan
@ 2014-05-13 9:05 ` Ley Foon Tan
2014-05-13 9:05 ` [PATCH 14/25] mips: " Ley Foon Tan
` (13 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:05 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, Michal Simek
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/microblaze/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/microblaze/include/uapi/asm/posix_types.h b/arch/microblaze/include/uapi/asm/posix_types.h
index 0e15039..20e5d98 100644
--- a/arch/microblaze/include/uapi/asm/posix_types.h
+++ b/arch/microblaze/include/uapi/asm/posix_types.h
@@ -4,6 +4,12 @@
typedef unsigned short __kernel_mode_t;
#define __kernel_mode_t __kernel_mode_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _ASM_MICROBLAZE_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 14/25] mips: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (11 preceding siblings ...)
2014-05-13 9:05 ` [PATCH 13/25] microblaze: " Ley Foon Tan
@ 2014-05-13 9:05 ` Ley Foon Tan
2014-05-13 9:05 ` [PATCH 15/25] mn10300: " Ley Foon Tan
` (12 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:05 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Ralf Baechle, linux-mips
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/mips/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/include/uapi/asm/posix_types.h b/arch/mips/include/uapi/asm/posix_types.h
index fa03ec3..e9ca921 100644
--- a/arch/mips/include/uapi/asm/posix_types.h
+++ b/arch/mips/include/uapi/asm/posix_types.h
@@ -25,6 +25,12 @@ typedef struct {
long val[2];
} __kernel_fsid_t;
#define __kernel_fsid_t __kernel_fsid_t
+
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
#endif
#include <asm-generic/posix_types.h>
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 15/25] mn10300: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (12 preceding siblings ...)
2014-05-13 9:05 ` [PATCH 14/25] mips: " Ley Foon Tan
@ 2014-05-13 9:05 ` Ley Foon Tan
2014-05-13 9:05 ` [PATCH 16/25] openrisc: " Ley Foon Tan
` (11 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:05 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, David Howells,
Koichi Yasutake, linux-am33-list
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/mn10300/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/mn10300/include/uapi/asm/posix_types.h b/arch/mn10300/include/uapi/asm/posix_types.h
index d31eeea..669ed1b 100644
--- a/arch/mn10300/include/uapi/asm/posix_types.h
+++ b/arch/mn10300/include/uapi/asm/posix_types.h
@@ -40,6 +40,12 @@ typedef int __kernel_ptrdiff_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _ASM_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 16/25] openrisc: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (13 preceding siblings ...)
2014-05-13 9:05 ` [PATCH 15/25] mn10300: " Ley Foon Tan
@ 2014-05-13 9:05 ` Ley Foon Tan
2014-05-13 9:30 ` Jonas Bonn
2014-05-13 9:06 ` [PATCH 17/25] parisc: " Ley Foon Tan
` (10 subsequent siblings)
25 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:05 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Jonas Bonn, linux
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/openrisc/include/asm/Kbuild | 1 -
arch/openrisc/include/uapi/asm/Kbuild | 1 +
arch/openrisc/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/openrisc/include/uapi/asm/posix_types.h
diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild
index 480af0d..3da7847 100644
--- a/arch/openrisc/include/asm/Kbuild
+++ b/arch/openrisc/include/asm/Kbuild
@@ -42,7 +42,6 @@ generic-y += msgbuf.h
generic-y += pci.h
generic-y += percpu.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += scatterlist.h
diff --git a/arch/openrisc/include/uapi/asm/Kbuild b/arch/openrisc/include/uapi/asm/Kbuild
index 80761eb..c09b436 100644
--- a/arch/openrisc/include/uapi/asm/Kbuild
+++ b/arch/openrisc/include/uapi/asm/Kbuild
@@ -5,6 +5,7 @@ header-y += byteorder.h
header-y += elf.h
header-y += kvm_para.h
header-y += param.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += sigcontext.h
header-y += unistd.h
diff --git a/arch/openrisc/include/uapi/asm/posix_types.h b/arch/openrisc/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..5ccf37d
--- /dev/null
+++ b/arch/openrisc/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_OPENRISC_POSIX_TYPES_H
+#define __ARCH_OPENRISC_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 17/25] parisc: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (14 preceding siblings ...)
2014-05-13 9:05 ` [PATCH 16/25] openrisc: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 20:17 ` Helge Deller
2014-05-13 9:06 ` [PATCH 19/25] s390: " Ley Foon Tan
` (9 subsequent siblings)
25 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, James E.J. Bottomley,
Helge Deller, linux-parisc
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/parisc/include/uapi/asm/posix_types.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/parisc/include/uapi/asm/posix_types.h b/arch/parisc/include/uapi/asm/posix_types.h
index b934425..21fcf1c 100644
--- a/arch/parisc/include/uapi/asm/posix_types.h
+++ b/arch/parisc/include/uapi/asm/posix_types.h
@@ -19,6 +19,14 @@ typedef int __kernel_suseconds_t;
typedef long long __kernel_off64_t;
typedef unsigned long long __kernel_ino64_t;
+#ifndef CONFIG_64BIT
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+#endif
+
#include <asm-generic/posix_types.h>
#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 19/25] s390: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (15 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 17/25] parisc: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 20/25] score: " Ley Foon Tan
` (8 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Martin Schwidefsky,
Heiko Carstens, linux390
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/s390/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/include/uapi/asm/posix_types.h b/arch/s390/include/uapi/asm/posix_types.h
index bf2a2ad..95729a3 100644
--- a/arch/s390/include/uapi/asm/posix_types.h
+++ b/arch/s390/include/uapi/asm/posix_types.h
@@ -28,6 +28,12 @@ typedef unsigned short __kernel_uid_t;
typedef unsigned short __kernel_gid_t;
typedef int __kernel_ptrdiff_t;
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#else /* __s390x__ */
typedef unsigned int __kernel_ino_t;
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 20/25] score: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (16 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 19/25] s390: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 21/25] sh: " Ley Foon Tan
` (7 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Chen Liqin, Lennox Wu
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/score/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/score/include/uapi/asm/posix_types.h b/arch/score/include/uapi/asm/posix_types.h
index b88acf8..4c3843a 100644
--- a/arch/score/include/uapi/asm/posix_types.h
+++ b/arch/score/include/uapi/asm/posix_types.h
@@ -1,6 +1,12 @@
#ifndef _ASM_SCORE_POSIX_TYPES_H
#define _ASM_SCORE_POSIX_TYPES_H
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _ASM_SCORE_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 21/25] sh: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (17 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 20/25] score: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 22/25] sparc: " Ley Foon Tan
` (6 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, linux-sh
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/sh/include/uapi/asm/posix_types_32.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/sh/include/uapi/asm/posix_types_32.h b/arch/sh/include/uapi/asm/posix_types_32.h
index ba0bdc4..cfc4331 100644
--- a/arch/sh/include/uapi/asm/posix_types_32.h
+++ b/arch/sh/include/uapi/asm/posix_types_32.h
@@ -17,6 +17,12 @@ typedef unsigned short __kernel_old_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* __ASM_SH_POSIX_TYPES_32_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 22/25] sparc: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (18 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 21/25] sh: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 23/25] unicore32: " Ley Foon Tan
` (5 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, David S. Miller, sparclinux
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/sparc/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/sparc/include/uapi/asm/posix_types.h b/arch/sparc/include/uapi/asm/posix_types.h
index 156220e..c5eaaef 100644
--- a/arch/sparc/include/uapi/asm/posix_types.h
+++ b/arch/sparc/include/uapi/asm/posix_types.h
@@ -42,6 +42,12 @@ typedef long __kernel_daddr_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#endif /* defined(__sparc__) && defined(__arch64__) */
#include <asm-generic/posix_types.h>
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 23/25] unicore32: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (19 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 22/25] sparc: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 25/25] xtense: " Ley Foon Tan
` (4 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel; +Cc: Ley Foon Tan, lftan.linux, cltang, Guan Xuetao
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/unicore32/include/asm/Kbuild | 1 -
arch/unicore32/include/uapi/asm/Kbuild | 1 +
arch/unicore32/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/unicore32/include/uapi/asm/posix_types.h
diff --git a/arch/unicore32/include/asm/Kbuild b/arch/unicore32/include/asm/Kbuild
index 1e5fb87..9742390 100644
--- a/arch/unicore32/include/asm/Kbuild
+++ b/arch/unicore32/include/asm/Kbuild
@@ -33,7 +33,6 @@ generic-y += param.h
generic-y += parport.h
generic-y += percpu.h
generic-y += poll.h
-generic-y += posix_types.h
generic-y += preempt.h
generic-y += resource.h
generic-y += scatterlist.h
diff --git a/arch/unicore32/include/uapi/asm/Kbuild b/arch/unicore32/include/uapi/asm/Kbuild
index 0514d7a..3eeb84a 100644
--- a/arch/unicore32/include/uapi/asm/Kbuild
+++ b/arch/unicore32/include/uapi/asm/Kbuild
@@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
header-y += byteorder.h
header-y += kvm_para.h
+header-y += posix_types.h
header-y += ptrace.h
header-y += sigcontext.h
header-y += unistd.h
diff --git a/arch/unicore32/include/uapi/asm/posix_types.h b/arch/unicore32/include/uapi/asm/posix_types.h
new file mode 100644
index 0000000..3c9dd54
--- /dev/null
+++ b/arch/unicore32/include/uapi/asm/posix_types.h
@@ -0,0 +1,17 @@
+#ifndef __ARCH_UNICORE32_POSIX_TYPES_H
+#define __ARCH_UNICORE32_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
+#include <asm-generic/posix_types.h>
+
+#endif
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 25/25] xtense: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (20 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 23/25] unicore32: " Ley Foon Tan
@ 2014-05-13 9:06 ` Ley Foon Tan
2014-05-13 9:10 ` [PATCH 07/25] cris: " Ley Foon Tan
` (3 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:06 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Chris Zankel, Max Filippov,
linux-xtensa
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/xtensa/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/xtensa/include/uapi/asm/posix_types.h b/arch/xtensa/include/uapi/asm/posix_types.h
index 6e96be0..0001106 100644
--- a/arch/xtensa/include/uapi/asm/posix_types.h
+++ b/arch/xtensa/include/uapi/asm/posix_types.h
@@ -34,6 +34,12 @@ typedef unsigned short __kernel_old_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _XTENSA_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH 07/25] cris: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (21 preceding siblings ...)
2014-05-13 9:06 ` [PATCH 25/25] xtense: " Ley Foon Tan
@ 2014-05-13 9:10 ` Ley Foon Tan
2014-05-13 9:10 ` [PATCH 00/25] Change time_t and clock_t to 64 bit Geert Uytterhoeven
` (2 subsequent siblings)
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:10 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Mikael Starvik,
Jesper Nilsson, linux-cris-kernel
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/cris/include/uapi/asm/posix_types.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/cris/include/uapi/asm/posix_types.h b/arch/cris/include/uapi/asm/posix_types.h
index 0f22e6a..334499a 100644
--- a/arch/cris/include/uapi/asm/posix_types.h
+++ b/arch/cris/include/uapi/asm/posix_types.h
@@ -25,6 +25,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* __ARCH_CRIS_POSIX_TYPES_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (22 preceding siblings ...)
2014-05-13 9:10 ` [PATCH 07/25] cris: " Ley Foon Tan
@ 2014-05-13 9:10 ` Geert Uytterhoeven
2014-05-13 9:23 ` Ley Foon Tan
2014-05-13 15:24 ` Christoph Hellwig
2014-05-14 3:36 ` [PATCH 24/25] x86: Add 32 bit time_t and clock_t Ley Foon Tan
25 siblings, 1 reply; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-13 9:10 UTC (permalink / raw)
To: Ley Foon Tan
Cc: Linux-Arch, linux-kernel, LeyFoon Tan, Chung-Lin Tang, Arnd Bergmann
Hi,
On Tue, May 13, 2014 at 10:57 AM, Ley Foon Tan <lftan@altera.com> wrote:
> This patchset change default time_t and clock_t to 64 bit in
> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
> these define to 32 bit in arch posix_types.h.
Thanks for your series!
> Ley Foon Tan (25):
> asm-generic: Change time_t and clock_t to 64 bit
For bisectability, this should be the last change, not the first.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 9:02 ` [PATCH 01/25] asm-generic: " Ley Foon Tan
@ 2014-05-13 9:15 ` James Hogan
2014-05-13 9:30 ` Thomas Gleixner
2014-05-13 9:32 ` Ley Foon Tan
0 siblings, 2 replies; 96+ messages in thread
From: James Hogan @ 2014-05-13 9:15 UTC (permalink / raw)
To: Ley Foon Tan; +Cc: linux-arch, LKML, lftan.linux, cltang, Arnd Bergmann
Hi,
On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
> Use 64 bit time_t and clock_t as default. 32 bit users can provide
> an override to define these as "long" if needed.
>
> Signed-off-by: Ley Foon Tan <lftan@altera.com>
> ---
> include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
> index fe74fcc..3f0e613 100644
> --- a/include/uapi/asm-generic/posix_types.h
> +++ b/include/uapi/asm-generic/posix_types.h
> @@ -81,12 +81,22 @@ typedef struct {
> #endif
>
> /*
> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
> + * define these as "long" if needed.
> + */
> +#ifndef __kernel_time_t
> +typedef long long __kernel_time_t;
> +#endif
> +
> +#ifndef __kernel_clock_t
> +typedef long long __kernel_clock_t;
> +#endif
I think having this as the first patch in the series will break
bisection for existing 32-bit arches. This needs to be done in such a
way that at no intermediate commit are __kernel_time_t or
__kernel_clock_t the wrong size for existing arches, e.g. by having a
first patch which makes the typedefs conditional but leaves them as
__kernel_long_t, and a final patch that changes the default after all
the arches have got their overrides in place.
Cheers
James
> +
> +/*
> * anything below here should be completely generic
> */
> typedef __kernel_long_t __kernel_off_t;
> typedef long long __kernel_loff_t;
> -typedef __kernel_long_t __kernel_time_t;
> -typedef __kernel_long_t __kernel_clock_t;
> typedef int __kernel_timer_t;
> typedef int __kernel_clockid_t;
> typedef char * __kernel_caddr_t;
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 12/25] metag: Add 32 bit time_t and clock_t
2014-05-13 9:04 ` [PATCH 12/25] metag: " Ley Foon Tan
@ 2014-05-13 9:22 ` James Hogan
2014-05-13 9:28 ` Ley Foon Tan
0 siblings, 1 reply; 96+ messages in thread
From: James Hogan @ 2014-05-13 9:22 UTC (permalink / raw)
To: Ley Foon Tan, linux-arch, linux-kernel; +Cc: lftan.linux, cltang, linux-metag
Hi,
On 13/05/14 10:04, Ley Foon Tan wrote:
> Override time_t and clock_t in include/uapi/asm-generic.
>
> Signed-off-by: Ley Foon Tan <lftan@altera.com>
> ---
> arch/metag/include/asm/Kbuild | 1 -
> arch/metag/include/uapi/asm/Kbuild | 1 +
> arch/metag/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/metag/include/uapi/asm/posix_types.h
>
> diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild
> index c29ead8..5a97e0d6 100644
> --- a/arch/metag/include/asm/Kbuild
> +++ b/arch/metag/include/asm/Kbuild
> @@ -31,7 +31,6 @@ generic-y += param.h
> generic-y += pci.h
> generic-y += percpu.h
> generic-y += poll.h
> -generic-y += posix_types.h
> generic-y += preempt.h
> generic-y += scatterlist.h
> generic-y += sections.h
> diff --git a/arch/metag/include/uapi/asm/Kbuild b/arch/metag/include/uapi/asm/Kbuild
> index 84e09fe..1542689 100644
> --- a/arch/metag/include/uapi/asm/Kbuild
> +++ b/arch/metag/include/uapi/asm/Kbuild
> @@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
>
> header-y += byteorder.h
> header-y += ech.h
> +header-y += posix_types.h
I don't think you need this. The file
include/uapi/asm-generic/Kbuild.asm which is included at the top of each
arches uapi/asm/Kbuild already has it.
(Admittedly there's already a lot of duplication of these that should
probably be fixed at some point).
Other than that it looks okay to me.
Cheers
James
> header-y += ptrace.h
> header-y += resource.h
> header-y += sigcontext.h
> diff --git a/arch/metag/include/uapi/asm/posix_types.h b/arch/metag/include/uapi/asm/posix_types.h
> new file mode 100644
> index 0000000..d643b22
> --- /dev/null
> +++ b/arch/metag/include/uapi/asm/posix_types.h
> @@ -0,0 +1,17 @@
> +#ifndef __ARCH_METAG_POSIX_TYPES_H
> +#define __ARCH_METAG_POSIX_TYPES_H
> +
> +/*
> + * This file is generally used by user-level software, so you need to
> + * be a little careful about namespace pollution etc. Also, we cannot
> + * assume GCC is being used.
> + */
> +typedef long __kernel_time_t;
> +#define __kernel_time_t __kernel_time_t
> +
> +typedef long __kernel_clock_t;
> +#define __kernel_clock_t __kernel_clock_t
> +
> +#include <asm-generic/posix_types.h>
> +
> +#endif
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 9:10 ` [PATCH 00/25] Change time_t and clock_t to 64 bit Geert Uytterhoeven
@ 2014-05-13 9:23 ` Ley Foon Tan
0 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, Arnd Bergmann
On Tue, May 13, 2014 at 5:10 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi,
>
> On Tue, May 13, 2014 at 10:57 AM, Ley Foon Tan <lftan@altera.com> wrote:
>> This patchset change default time_t and clock_t to 64 bit in
>> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
>> these define to 32 bit in arch posix_types.h.
>
> Thanks for your series!
>
>> Ley Foon Tan (25):
>> asm-generic: Change time_t and clock_t to 64 bit
>
> For bisectability, this should be the last change, not the first.
Noted, will put this as last patch in next revision.
Thanks.
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 12/25] metag: Add 32 bit time_t and clock_t
2014-05-13 9:22 ` James Hogan
@ 2014-05-13 9:28 ` Ley Foon Tan
0 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:28 UTC (permalink / raw)
To: James Hogan; +Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, linux-metag
On Tue, May 13, 2014 at 5:22 PM, James Hogan <james.hogan@imgtec.com> wrote:
> Hi,
>
> On 13/05/14 10:04, Ley Foon Tan wrote:
>> Override time_t and clock_t in include/uapi/asm-generic.
>>
>> Signed-off-by: Ley Foon Tan <lftan@altera.com>
>> ---
>> arch/metag/include/asm/Kbuild | 1 -
>> arch/metag/include/uapi/asm/Kbuild | 1 +
>> arch/metag/include/uapi/asm/posix_types.h | 17 +++++++++++++++++
>> 3 files changed, 18 insertions(+), 1 deletion(-)
>> create mode 100644 arch/metag/include/uapi/asm/posix_types.h
>>
>> diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild
>> index c29ead8..5a97e0d6 100644
>> --- a/arch/metag/include/asm/Kbuild
>> +++ b/arch/metag/include/asm/Kbuild
>> @@ -31,7 +31,6 @@ generic-y += param.h
>> generic-y += pci.h
>> generic-y += percpu.h
>> generic-y += poll.h
>> -generic-y += posix_types.h
>> generic-y += preempt.h
>> generic-y += scatterlist.h
>> generic-y += sections.h
>> diff --git a/arch/metag/include/uapi/asm/Kbuild b/arch/metag/include/uapi/asm/Kbuild
>> index 84e09fe..1542689 100644
>> --- a/arch/metag/include/uapi/asm/Kbuild
>> +++ b/arch/metag/include/uapi/asm/Kbuild
>> @@ -3,6 +3,7 @@ include include/uapi/asm-generic/Kbuild.asm
>>
>> header-y += byteorder.h
>> header-y += ech.h
>> +header-y += posix_types.h
>
> I don't think you need this. The file
> include/uapi/asm-generic/Kbuild.asm which is included at the top of each
> arches uapi/asm/Kbuild already has it.
> (Admittedly there's already a lot of duplication of these that should
> probably be fixed at some point).
>
> Other than that it looks okay to me.
Okay, will remove this.
Thanks.
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 16/25] openrisc: Add 32 bit time_t and clock_t
2014-05-13 9:05 ` [PATCH 16/25] openrisc: " Ley Foon Tan
@ 2014-05-13 9:30 ` Jonas Bonn
2014-05-13 9:41 ` Ley Foon Tan
0 siblings, 1 reply; 96+ messages in thread
From: Jonas Bonn @ 2014-05-13 9:30 UTC (permalink / raw)
To: Ley Foon Tan, linux-arch, linux-kernel; +Cc: lftan.linux, cltang, linux
On 05/13/2014 11:05 AM, Ley Foon Tan wrote:
> Override time_t and clock_t in include/uapi/asm-generic.
>
> diff --git a/arch/openrisc/include/uapi/asm/posix_types.h b/arch/openrisc/include/uapi/asm/posix_types.h
> new file mode 100644
> index 0000000..5ccf37d
> --- /dev/null
> +++ b/arch/openrisc/include/uapi/asm/posix_types.h
> @@ -0,0 +1,17 @@
> +#ifndef __ARCH_OPENRISC_POSIX_TYPES_H
> +#define __ARCH_OPENRISC_POSIX_TYPES_H
> +
> +/*
> + * This file is generally used by user-level software, so you need to
> + * be a little careful about namespace pollution etc. Also, we cannot
> + * assume GCC is being used.
> + */
I don't think the above comment needs to be copied to this file... given
that the file is in the uapi/ directory, we know the file is exported to
userspace, and the GCC comment isn't relevant given the rest of the
files contents.
But that's really just a nit! Nice work, otherwise.
Acked-by: Jonas Bonn <jonas@southpole.se>
> +typedef long __kernel_time_t;
> +#define __kernel_time_t __kernel_time_t
> +
> +typedef long __kernel_clock_t;
> +#define __kernel_clock_t __kernel_clock_t
> +
> +#include <asm-generic/posix_types.h>
> +
> +#endif
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 9:15 ` James Hogan
@ 2014-05-13 9:30 ` Thomas Gleixner
2014-05-13 9:32 ` Ley Foon Tan
1 sibling, 0 replies; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-13 9:30 UTC (permalink / raw)
To: James Hogan
Cc: Ley Foon Tan, linux-arch, LKML, lftan.linux, cltang, Arnd Bergmann
On Tue, 13 May 2014, James Hogan wrote:
> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
> > Use 64 bit time_t and clock_t as default. 32 bit users can provide
> > an override to define these as "long" if needed.
> >
> > Signed-off-by: Ley Foon Tan <lftan@altera.com>
> > ---
> > include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
> > index fe74fcc..3f0e613 100644
> > --- a/include/uapi/asm-generic/posix_types.h
> > +++ b/include/uapi/asm-generic/posix_types.h
> > @@ -81,12 +81,22 @@ typedef struct {
> > #endif
> >
> > /*
> > + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
> > + * define these as "long" if needed.
> > + */
> > +#ifndef __kernel_time_t
> > +typedef long long __kernel_time_t;
> > +#endif
> > +
> > +#ifndef __kernel_clock_t
> > +typedef long long __kernel_clock_t;
> > +#endif
>
> I think having this as the first patch in the series will break
> bisection for existing 32-bit arches. This needs to be done in such a
> way that at no intermediate commit are __kernel_time_t or
> __kernel_clock_t the wrong size for existing arches, e.g. by having a
> first patch which makes the typedefs conditional but leaves them as
> __kernel_long_t, and a final patch that changes the default after all
> the arches have got their overrides in place.
And instead of having a gazillion of pointless include file changes
which all do the same thing, this should simply use a config switch.
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 9:15 ` James Hogan
2014-05-13 9:30 ` Thomas Gleixner
@ 2014-05-13 9:32 ` Ley Foon Tan
2014-05-13 9:50 ` James Hogan
1 sibling, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:32 UTC (permalink / raw)
To: James Hogan; +Cc: Linux-Arch, LKML, Chung-Lin Tang, Arnd Bergmann
On Tue, May 13, 2014 at 5:15 PM, James Hogan <james.hogan@imgtec.com> wrote:
> Hi,
>
> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
>> Use 64 bit time_t and clock_t as default. 32 bit users can provide
>> an override to define these as "long" if needed.
>>
>> Signed-off-by: Ley Foon Tan <lftan@altera.com>
>> ---
>> include/uapi/asm-generic/posix_types.h | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
>> index fe74fcc..3f0e613 100644
>> --- a/include/uapi/asm-generic/posix_types.h
>> +++ b/include/uapi/asm-generic/posix_types.h
>> @@ -81,12 +81,22 @@ typedef struct {
>> #endif
>>
>> /*
>> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
>> + * define these as "long" if needed.
>> + */
>> +#ifndef __kernel_time_t
>> +typedef long long __kernel_time_t;
>> +#endif
>> +
>> +#ifndef __kernel_clock_t
>> +typedef long long __kernel_clock_t;
>> +#endif
>
> I think having this as the first patch in the series will break
> bisection for existing 32-bit arches. This needs to be done in such a
> way that at no intermediate commit are __kernel_time_t or
> __kernel_clock_t the wrong size for existing arches, e.g. by having a
> first patch which makes the typedefs conditional but leaves them as
> __kernel_long_t, and a final patch that changes the default after all
> the arches have got their overrides in place.
Your suggestion is something as below?
First patch:
#ifndef __kernel_time_t
typedef __kernel_long_t __kernel_time_t;
#endif
Last patch:
#ifndef __kernel_time_t
typedef long long __kernel_time_t;
#endif
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 16/25] openrisc: Add 32 bit time_t and clock_t
2014-05-13 9:30 ` Jonas Bonn
@ 2014-05-13 9:41 ` Ley Foon Tan
0 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 9:41 UTC (permalink / raw)
To: Jonas Bonn; +Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, linux
On Tue, May 13, 2014 at 5:30 PM, Jonas Bonn <jonas@southpole.se> wrote:
> On 05/13/2014 11:05 AM, Ley Foon Tan wrote:
>> Override time_t and clock_t in include/uapi/asm-generic.
>>
>> diff --git a/arch/openrisc/include/uapi/asm/posix_types.h b/arch/openrisc/include/uapi/asm/posix_types.h
>> new file mode 100644
>> index 0000000..5ccf37d
>> --- /dev/null
>> +++ b/arch/openrisc/include/uapi/asm/posix_types.h
>> @@ -0,0 +1,17 @@
>> +#ifndef __ARCH_OPENRISC_POSIX_TYPES_H
>> +#define __ARCH_OPENRISC_POSIX_TYPES_H
>> +
>> +/*
>> + * This file is generally used by user-level software, so you need to
>> + * be a little careful about namespace pollution etc. Also, we cannot
>> + * assume GCC is being used.
>> + */
>
> I don't think the above comment needs to be copied to this file... given
> that the file is in the uapi/ directory, we know the file is exported to
> userspace, and the GCC comment isn't relevant given the rest of the
> files contents.
>
> But that's really just a nit! Nice work, otherwise.
>
> Acked-by: Jonas Bonn <jonas@southpole.se>
I noticed most of the posix_types.h files in other archiectures have
this comment.
I can remove this comment if you think we don't need to add this.
Thanks.
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 9:32 ` Ley Foon Tan
@ 2014-05-13 9:50 ` James Hogan
2014-05-13 10:17 ` Ley Foon Tan
0 siblings, 1 reply; 96+ messages in thread
From: James Hogan @ 2014-05-13 9:50 UTC (permalink / raw)
To: Ley Foon Tan
Cc: Linux-Arch, LKML, Chung-Lin Tang, Arnd Bergmann, Thomas Gleixner
Hi,
On 13/05/14 10:32, Ley Foon Tan wrote:
> On Tue, May 13, 2014 at 5:15 PM, James Hogan <james.hogan@imgtec.com> wrote:
>> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
>>> /*
>>> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
>>> + * define these as "long" if needed.
>>> + */
>>> +#ifndef __kernel_time_t
>>> +typedef long long __kernel_time_t;
>>> +#endif
>>> +
>>> +#ifndef __kernel_clock_t
>>> +typedef long long __kernel_clock_t;
>>> +#endif
>>
>> I think having this as the first patch in the series will break
>> bisection for existing 32-bit arches. This needs to be done in such a
>> way that at no intermediate commit are __kernel_time_t or
>> __kernel_clock_t the wrong size for existing arches, e.g. by having a
>> first patch which makes the typedefs conditional but leaves them as
>> __kernel_long_t, and a final patch that changes the default after all
>> the arches have got their overrides in place.
>
> Your suggestion is something as below?
Yeh, although I like Thomas' idea better, then each existing 32-bit arch
can just select the Kconfig symbol to get the smaller type.
IIRC Kconfig won't even complain if you select a symbol which doesn't
exist yet.
Cheers
James
>
> First patch:
> #ifndef __kernel_time_t
> typedef __kernel_long_t __kernel_time_t;
> #endif
>
> Last patch:
> #ifndef __kernel_time_t
> typedef long long __kernel_time_t;
> #endif
>
> Ley Foon
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 9:50 ` James Hogan
@ 2014-05-13 10:17 ` Ley Foon Tan
2014-05-13 10:21 ` Arnd Bergmann
2014-05-13 10:22 ` James Hogan
0 siblings, 2 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-13 10:17 UTC (permalink / raw)
To: James Hogan
Cc: Linux-Arch, LKML, Chung-Lin Tang, Arnd Bergmann, Thomas Gleixner
On Tue, May 13, 2014 at 5:50 PM, James Hogan <james.hogan@imgtec.com> wrote:
> Hi,
>
> On 13/05/14 10:32, Ley Foon Tan wrote:
>> On Tue, May 13, 2014 at 5:15 PM, James Hogan <james.hogan@imgtec.com> wrote:
>>> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
>>>> /*
>>>> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
>>>> + * define these as "long" if needed.
>>>> + */
>>>> +#ifndef __kernel_time_t
>>>> +typedef long long __kernel_time_t;
>>>> +#endif
>>>> +
>>>> +#ifndef __kernel_clock_t
>>>> +typedef long long __kernel_clock_t;
>>>> +#endif
>>>
>>> I think having this as the first patch in the series will break
>>> bisection for existing 32-bit arches. This needs to be done in such a
>>> way that at no intermediate commit are __kernel_time_t or
>>> __kernel_clock_t the wrong size for existing arches, e.g. by having a
>>> first patch which makes the typedefs conditional but leaves them as
>>> __kernel_long_t, and a final patch that changes the default after all
>>> the arches have got their overrides in place.
>>
>> Your suggestion is something as below?
>
> Yeh, although I like Thomas' idea better, then each existing 32-bit arch
> can just select the Kconfig symbol to get the smaller type.
>
> IIRC Kconfig won't even complain if you select a symbol which doesn't
> exist yet.
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?
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 10:17 ` Ley Foon Tan
@ 2014-05-13 10:21 ` Arnd Bergmann
2014-05-13 12:07 ` Thomas Gleixner
2014-05-13 10:22 ` James Hogan
1 sibling, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-13 10:21 UTC (permalink / raw)
To: Ley Foon Tan
Cc: James Hogan, Linux-Arch, LKML, Chung-Lin Tang, Thomas Gleixner
On Tuesday 13 May 2014 18:17:40 Ley Foon Tan wrote:
> On Tue, May 13, 2014 at 5:50 PM, James Hogan <james.hogan@imgtec.com> wrote:
> > Hi,
> >
> > On 13/05/14 10:32, Ley Foon Tan wrote:
> >> On Tue, May 13, 2014 at 5:15 PM, James Hogan <james.hogan@imgtec.com> wrote:
> >>> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
> >>>> /*
> >>>> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
> >>>> + * define these as "long" if needed.
> >>>> + */
> >>>> +#ifndef __kernel_time_t
> >>>> +typedef long long __kernel_time_t;
> >>>> +#endif
> >>>> +
> >>>> +#ifndef __kernel_clock_t
> >>>> +typedef long long __kernel_clock_t;
> >>>> +#endif
> >>>
> >>> I think having this as the first patch in the series will break
> >>> bisection for existing 32-bit arches. This needs to be done in such a
> >>> way that at no intermediate commit are __kernel_time_t or
> >>> __kernel_clock_t the wrong size for existing arches, e.g. by having a
> >>> first patch which makes the typedefs conditional but leaves them as
> >>> __kernel_long_t, and a final patch that changes the default after all
> >>> the arches have got their overrides in place.
> >>
> >> Your suggestion is something as below?
> >
> > Yeh, although I like Thomas' idea better, then each existing 32-bit arch
> > can just select the Kconfig symbol to get the smaller type.
> >
> > IIRC Kconfig won't even complain if you select a symbol which doesn't
> > exist yet.
> 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.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 10:17 ` Ley Foon Tan
2014-05-13 10:21 ` Arnd Bergmann
@ 2014-05-13 10:22 ` James Hogan
2014-05-14 3:47 ` H. Peter Anvin
1 sibling, 1 reply; 96+ messages in thread
From: James Hogan @ 2014-05-13 10:22 UTC (permalink / raw)
To: Ley Foon Tan
Cc: Linux-Arch, LKML, Chung-Lin Tang, Arnd Bergmann, Thomas Gleixner
On 13/05/14 11:17, Ley Foon Tan wrote:
> On Tue, May 13, 2014 at 5:50 PM, James Hogan <james.hogan@imgtec.com> wrote:
>> Hi,
>>
>> On 13/05/14 10:32, Ley Foon Tan wrote:
>>> On Tue, May 13, 2014 at 5:15 PM, James Hogan <james.hogan@imgtec.com> wrote:
>>>> On 13 May 2014 10:02, Ley Foon Tan <lftan@altera.com> wrote:
>>>>> /*
>>>>> + * Use 64 bit time_t and clock_t as default. 32 bit users can provide an override to
>>>>> + * define these as "long" if needed.
>>>>> + */
>>>>> +#ifndef __kernel_time_t
>>>>> +typedef long long __kernel_time_t;
>>>>> +#endif
>>>>> +
>>>>> +#ifndef __kernel_clock_t
>>>>> +typedef long long __kernel_clock_t;
>>>>> +#endif
>>>>
>>>> I think having this as the first patch in the series will break
>>>> bisection for existing 32-bit arches. This needs to be done in such a
>>>> way that at no intermediate commit are __kernel_time_t or
>>>> __kernel_clock_t the wrong size for existing arches, e.g. by having a
>>>> first patch which makes the typedefs conditional but leaves them as
>>>> __kernel_long_t, and a final patch that changes the default after all
>>>> the arches have got their overrides in place.
>>>
>>> Your suggestion is something as below?
>>
>> Yeh, although I like Thomas' idea better, then each existing 32-bit arch
>> can just select the Kconfig symbol to get the smaller type.
>>
>> IIRC Kconfig won't even complain if you select a symbol which doesn't
>> exist yet.
> 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?
Yeh, good point, that won't work.
Cheers
James
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 10:21 ` Arnd Bergmann
@ 2014-05-13 12:07 ` Thomas Gleixner
2014-05-13 13:11 ` Geert Uytterhoeven
0 siblings, 1 reply; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-13 12:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Ley Foon Tan, James Hogan, Linux-Arch, LKML, Chung-Lin Tang
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.
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 12:07 ` Thomas Gleixner
@ 2014-05-13 13:11 ` Geert Uytterhoeven
2014-05-13 13:38 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-13 13:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Arnd Bergmann, Ley Foon Tan, James Hogan, Linux-Arch, LKML,
Chung-Lin Tang
On Tue, May 13, 2014 at 2:07 PM, Thomas Gleixner <tglx@linutronix.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).
Or is there another solution?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 13:11 ` Geert Uytterhoeven
@ 2014-05-13 13:38 ` Arnd Bergmann
2014-05-13 14:37 ` Thomas Gleixner
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-13 13:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Gleixner, Ley Foon Tan, James Hogan, Linux-Arch, LKML,
Chung-Lin Tang
On Tuesday 13 May 2014 15:11:33 Geert Uytterhoeven wrote:
> On Tue, May 13, 2014 at 2:07 PM, Thomas Gleixner <tglx@linutronix.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
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 13:38 ` Arnd Bergmann
@ 2014-05-13 14:37 ` Thomas Gleixner
0 siblings, 0 replies; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-13 14:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Ley Foon Tan, James Hogan, Linux-Arch, LKML,
Chung-Lin Tang
On Tue, 13 May 2014, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 15:11:33 Geert Uytterhoeven wrote:
> > On Tue, May 13, 2014 at 2:07 PM, Thomas Gleixner <tglx@linutronix.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.
The most simple solution is to use the existing unifdef machinery for
the export version and make the #ifdef maze use CONFIG_ARCH_XXX. For
the simple architectures you just need the CONFIG_ARCH_NAME, for such
which support 32 and 64 or some more ABI versions you need to look for
a matching one or a combination of several config options.
You even can combine that with versioning:
#ifdef CONFIG_ARCH_OPENRISC
# include <asm-generic/hdr-v31.h>
#endif
That gives you a nice history in a single place and avoids updating
the world and some when you change stuff.
Hmm?
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (23 preceding siblings ...)
2014-05-13 9:10 ` [PATCH 00/25] Change time_t and clock_t to 64 bit Geert Uytterhoeven
@ 2014-05-13 15:24 ` Christoph Hellwig
2014-05-13 15:33 ` Thomas Gleixner
2014-05-14 3:36 ` [PATCH 24/25] x86: Add 32 bit time_t and clock_t Ley Foon Tan
25 siblings, 1 reply; 96+ messages in thread
From: Christoph Hellwig @ 2014-05-13 15:24 UTC (permalink / raw)
To: Ley Foon Tan; +Cc: linux-arch, linux-kernel, lftan.linux, cltang, Arnd Bergmann
On Tue, May 13, 2014 at 04:57:36PM +0800, Ley Foon Tan wrote:
> This patchset change default time_t and clock_t to 64 bit in
> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
> these define to 32 bit in arch posix_types.h.
>
> There is request to support 64 bit time_t for new architecture [1]. According to the
I think this is an utterly wrong, and very dangerous approach. A 64-bit
time_t is something that will need non-trivial porting effort in
userland, and introducing it only for new fringe architectures is a
guaranteed way to create silent breakage.
If you do care about it make sure the architectures that are heavily
used support it and userland can properly deal with it first, and only
then default new architectures to it.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 15:24 ` Christoph Hellwig
@ 2014-05-13 15:33 ` Thomas Gleixner
2014-05-13 17:46 ` Christoph Hellwig
0 siblings, 1 reply; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-13 15:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ley Foon Tan, linux-arch, linux-kernel, lftan.linux, cltang,
Arnd Bergmann
On Tue, 13 May 2014, Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 04:57:36PM +0800, Ley Foon Tan wrote:
> > This patchset change default time_t and clock_t to 64 bit in
> > include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
> > these define to 32 bit in arch posix_types.h.
> >
> > There is request to support 64 bit time_t for new architecture [1]. According to the
>
> I think this is an utterly wrong, and very dangerous approach. A 64-bit
> time_t is something that will need non-trivial porting effort in
> userland, and introducing it only for new fringe architectures is a
> guaranteed way to create silent breakage.
>
> If you do care about it make sure the architectures that are heavily
> used support it and userland can properly deal with it first, and only
> then default new architectures to it.
Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
64bit time_t without breaking the world and some more.
All 64bit architectures use 64bit time_t already plus the x32 ABI of x86.
So why would user space explode? It did not explode with x32 and it
would be dumb as hell to have new archs use time_t 32bit when we are
currently twisting our brain around how to solve the y2038
problem. Simply because we can not do the BSD flag day approach and
change it.
User space needs to be audited anyway so there is nothing wrong if we
have a few more architectures aside of x32 using a 64bit time_t on a
32 bit machine.
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 15:33 ` Thomas Gleixner
@ 2014-05-13 17:46 ` Christoph Hellwig
2014-05-13 18:10 ` Arnd Bergmann
` (2 more replies)
0 siblings, 3 replies; 96+ messages in thread
From: Christoph Hellwig @ 2014-05-13 17:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ley Foon Tan, linux-arch, linux-kernel, lftan.linux, cltang,
Arnd Bergmann
On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
> 64bit time_t without breaking the world and some more.
Of course we can, we just need to still provide the existing 32-bit
time_t ABIs for backwards compatiblity. That's how we handled
extensions of other types like off_t in the past.
> All 64bit architectures use 64bit time_t already plus the x32 ABI of x86.
64-bit is not relevant for the pain as there time_t is simply a long,
while for 32-bit types we move to a longer than pointer sized type,
in direct contradiction to older standards the explicitly prohibit this.
> So why would user space explode? It did not explode with x32
Who knows? It's not like x32 actually has any significant user base.
In fact just weeks ago we fixed fundamental type system bugs for it.
> and it
> would be dumb as hell to have new archs use time_t 32bit when we are
> currently twisting our brain around how to solve the y2038
> problem. Simply because we can not do the BSD flag day approach and
> change it.
I don't think it's a good idea to have minor new architectures
pointlessly different than the major ones. Especially given that we'll
absolutely have to fir the y2038 problem for 32-bit arm and probably
x86 anyway.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 17:46 ` Christoph Hellwig
@ 2014-05-13 18:10 ` Arnd Bergmann
2014-05-13 18:24 ` Geert Uytterhoeven
2014-05-14 10:13 ` Ley Foon Tan
2014-05-13 18:15 ` Geert Uytterhoeven
2014-05-13 19:14 ` Thomas Gleixner
2 siblings, 2 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-13 18:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Thomas Gleixner, Ley Foon Tan, linux-arch, linux-kernel,
lftan.linux, cltang
On Tuesday 13 May 2014 10:46:40 Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> > and it
> > would be dumb as hell to have new archs use time_t 32bit when we are
> > currently twisting our brain around how to solve the y2038
> > problem. Simply because we can not do the BSD flag day approach and
> > change it.
>
> I don't think it's a good idea to have minor new architectures
> pointlessly different than the major ones. Especially given that we'll
> absolutely have to fir the y2038 problem for 32-bit arm and probably
> x86 anyway.
I've just spent two days looking at stuff that uses time_t inside
of the kernel, to get a better idea of what we actually need to
do to get provide new user interfaces for the existing architectures.
My impression so far is that we're better off fixing it for the
existing architectures first and then using the new interfaces
exclusively on new ones, rather than changing over the ABI for
all new architectures at this point, which would likely create
yet another variant to maintain in the long run.
Using 64-bit time_t on x32 is fine, because it's fast to operate
in user space with 64-bit registers, and the kernel is 64-bit
anyway. Inside of the kernel, we may get into trouble using
a 64-bit time_t on 32-bit architectures because of the overhead
in 64-bit math, e.g. all the timekeeping code that is based on
timespec or some code paths in file systems and network code where
we actually require division of time_t values.
We clearly have to change that code in some for to deal with y2038,
but 64-bit time_t may not be the best option. A lot of the
in-kernel code can probably use ktime_t, which we can change
to a different representation (e.g. 34 bit seconds) if needed,
and all the code that is only interested in relative time
(e.g. nanosleep) doesn't have to change at all.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 17:46 ` Christoph Hellwig
2014-05-13 18:10 ` Arnd Bergmann
@ 2014-05-13 18:15 ` Geert Uytterhoeven
2014-05-13 19:14 ` Thomas Gleixner
2 siblings, 0 replies; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-13 18:15 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Thomas Gleixner, Ley Foon Tan, Linux-Arch, linux-kernel,
LeyFoon Tan, Chung-Lin Tang, Arnd Bergmann
On Tue, May 13, 2014 at 7:46 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> and it
>> would be dumb as hell to have new archs use time_t 32bit when we are
>> currently twisting our brain around how to solve the y2038
>> problem. Simply because we can not do the BSD flag day approach and
>> change it.
>
> I don't think it's a good idea to have minor new architectures
> pointlessly different than the major ones. Especially given that we'll
> absolutely have to fir the y2038 problem for 32-bit arm and probably
> x86 anyway.
Considering someone just told me he plans to keep on using PPC
based MVME boards for 8 more years, you can expect some of today's
32-bit hardware to be around in 24 years...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 18:10 ` Arnd Bergmann
@ 2014-05-13 18:24 ` Geert Uytterhoeven
2014-05-13 19:32 ` Arnd Bergmann
2014-05-14 10:13 ` Ley Foon Tan
1 sibling, 1 reply; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-13 18:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 13 May 2014 10:46:40 Christoph Hellwig wrote:
>> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
>> > and it
>> > would be dumb as hell to have new archs use time_t 32bit when we are
>> > currently twisting our brain around how to solve the y2038
>> > problem. Simply because we can not do the BSD flag day approach and
>> > change it.
>>
>> I don't think it's a good idea to have minor new architectures
>> pointlessly different than the major ones. Especially given that we'll
>> absolutely have to fir the y2038 problem for 32-bit arm and probably
>> x86 anyway.
>
> I've just spent two days looking at stuff that uses time_t inside
> of the kernel, to get a better idea of what we actually need to
> do to get provide new user interfaces for the existing architectures.
>
> My impression so far is that we're better off fixing it for the
> existing architectures first and then using the new interfaces
> exclusively on new ones, rather than changing over the ABI for
> all new architectures at this point, which would likely create
> yet another variant to maintain in the long run.
Makes sense.
> Using 64-bit time_t on x32 is fine, because it's fast to operate
> in user space with 64-bit registers, and the kernel is 64-bit
> anyway. Inside of the kernel, we may get into trouble using
> a 64-bit time_t on 32-bit architectures because of the overhead
> in 64-bit math, e.g. all the timekeeping code that is based on
> timespec or some code paths in file systems and network code where
> we actually require division of time_t values.
While going over time_t uses, have you found a pattern for use cases
involving division of time_t values in filesystem and networking code?
> We clearly have to change that code in some for to deal with y2038,
> but 64-bit time_t may not be the best option. A lot of the
> in-kernel code can probably use ktime_t, which we can change
> to a different representation (e.g. 34 bit seconds) if needed,
> and all the code that is only interested in relative time
> (e.g. nanosleep) doesn't have to change at all.
Yeah. 32-bit uptimes should be good enough for everyone (don't quote
me on that), so adding a 64-bit offset when there's a need for absolute
time should be OK.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 17:46 ` Christoph Hellwig
2014-05-13 18:10 ` Arnd Bergmann
2014-05-13 18:15 ` Geert Uytterhoeven
@ 2014-05-13 19:14 ` Thomas Gleixner
2 siblings, 0 replies; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-13 19:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ley Foon Tan, linux-arch, linux-kernel, lftan.linux, cltang,
Arnd Bergmann
On Tue, 13 May 2014, Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> > Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
> > 64bit time_t without breaking the world and some more.
>
> Of course we can, we just need to still provide the existing 32-bit
> time_t ABIs for backwards compatiblity. That's how we handled
> extensions of other types like off_t in the past.
Sorry, misunderstood you there.
Sure, I agree that we need to fix it anyway plus all timespec/timeval
usage sites. It's on my and John Stultz radar as well. Just the sheer
amount of syscalls, ioctls etc. makes one shudder.
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 18:24 ` Geert Uytterhoeven
@ 2014-05-13 19:32 ` Arnd Bergmann
2014-05-13 20:35 ` Geert Uytterhoeven
2014-05-14 21:33 ` John Stultz
0 siblings, 2 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-13 19:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Using 64-bit time_t on x32 is fine, because it's fast to operate
> > in user space with 64-bit registers, and the kernel is 64-bit
> > anyway. Inside of the kernel, we may get into trouble using
> > a 64-bit time_t on 32-bit architectures because of the overhead
> > in 64-bit math, e.g. all the timekeeping code that is based on
> > timespec or some code paths in file systems and network code where
> > we actually require division of time_t values.
>
> While going over time_t uses, have you found a pattern for use cases
> involving division of time_t values in filesystem and networking code?
In ipv4, we have multiple places doing this:
icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC +
tv.tv_nsec / NSEC_PER_MSEC);
to calculate the miliseconds since midnight. For file systems, I
found that FAT uses seconds/minutes/hours/days/month/year representation,
which is a lot of divides, but that can probably be optimized and
we need to handle years beyond 2038 anyway.
> > We clearly have to change that code in some for to deal with y2038,
> > but 64-bit time_t may not be the best option. A lot of the
> > in-kernel code can probably use ktime_t, which we can change
> > to a different representation (e.g. 34 bit seconds) if needed,
> > and all the code that is only interested in relative time
> > (e.g. nanosleep) doesn't have to change at all.
>
> Yeah. 32-bit uptimes should be good enough for everyone (don't quote
> me on that), so adding a 64-bit offset when there's a need for absolute
> time should be OK.
I think we have three categories:
a) interfaces that uses relative time_t/timespec/timeval:
- nanosleep
- select/pselect/poll/ppoll/epoll
- getrusage
- sched_rr_get_interval
- sigtimedwait
- clock_nanosleep
- alarm
- siginfo (rusage)
These can stay compatible, but we'd have to use a different
type if we change time_t.
b) interfaces that don't make sense for times in the past:
- getitimer/setitimer
- timer_settime/timer_gettime
- gettimeofday/settimeofday
- adjtimex
- clock_gettime/clock_settime/clock_adjtime
- time/stime
- socket time stamps
- audio time stamps
- v4l time stamps
- input event time stamps
- sysv ipc (msg, sem, shm)
Here, we are relatively free to change the start of the
epoch in the kernel but convert to something else on the
user space boundary. One possibility is to scale them to
boot time and use ktime_t in the kernel.
c) interfaces that require absolute times:
- stat/lstat/fstatat/
- utime/utimes/futimesat
These absolutely have to use something better than time_t
both in user space and in the kernel so we can deal with
old files. A lot of file systems need to be fixed as well so
we can actually store the times, regardless of whether we
are running a 32 or 64 bit kernel.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 17/25] parisc: Add 32 bit time_t and clock_t
2014-05-13 9:06 ` [PATCH 17/25] parisc: " Ley Foon Tan
@ 2014-05-13 20:17 ` Helge Deller
2014-05-14 1:57 ` Ley Foon Tan
2014-05-15 0:34 ` H. Peter Anvin
0 siblings, 2 replies; 96+ messages in thread
From: Helge Deller @ 2014-05-13 20:17 UTC (permalink / raw)
To: Ley Foon Tan, linux-arch, linux-kernel
Cc: lftan.linux, cltang, James E.J. Bottomley, linux-parisc
Hi Ley,
On 05/13/2014 11:06 AM, Ley Foon Tan wrote:
> Override time_t and clock_t in include/uapi/asm-generic.
>
> Signed-off-by: Ley Foon Tan <lftan@altera.com>
> ---
> arch/parisc/include/uapi/asm/posix_types.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/parisc/include/uapi/asm/posix_types.h b/arch/parisc/include/uapi/asm/posix_types.h
> index b934425..21fcf1c 100644
> --- a/arch/parisc/include/uapi/asm/posix_types.h
> +++ b/arch/parisc/include/uapi/asm/posix_types.h
> @@ -19,6 +19,14 @@ typedef int __kernel_suseconds_t;
> typedef long long __kernel_off64_t;
> typedef unsigned long long __kernel_ino64_t;
>
> +#ifndef CONFIG_64BIT
We can't use CONFIG_64BIT for a userspace header file. Please use
#if !defined(__LP64__)
instead.
But even then I'm not sure if it's all correct...
Helge
> +typedef long __kernel_time_t;
> +#define __kernel_time_t __kernel_time_t
> +
> +typedef long __kernel_clock_t;
> +#define __kernel_clock_t __kernel_clock_t
> +#endif
> +
> #include <asm-generic/posix_types.h>
>
> #endif
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 04/25] avr32: Add 32 bit time_t and clock_t
2014-05-13 9:02 ` [PATCH 04/25] avr32: " Ley Foon Tan
@ 2014-05-13 20:19 ` Hans-Christian Egtvedt
2014-05-14 1:54 ` Ley Foon Tan
0 siblings, 1 reply; 96+ messages in thread
From: Hans-Christian Egtvedt @ 2014-05-13 20:19 UTC (permalink / raw)
To: Ley Foon Tan
Cc: linux-arch, linux-kernel, lftan.linux, cltang, Haavard Skinnemoen
Around Tue 13 May 2014 17:02:49 +0800 or thereabout, Ley Foon Tan wrote:
> Override time_t and clock_t in include/uapi/asm-generic.
>
> Signed-off-by: Ley Foon Tan <lftan@altera.com>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> ---
> arch/avr32/include/uapi/asm/posix_types.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/avr32/include/uapi/asm/posix_types.h b/arch/avr32/include/uapi/asm/posix_types.h
> index 5b813a8..47d5146 100644
> --- a/arch/avr32/include/uapi/asm/posix_types.h
> +++ b/arch/avr32/include/uapi/asm/posix_types.h
> @@ -32,6 +32,12 @@ typedef unsigned short __kernel_old_gid_t;
> typedef unsigned short __kernel_old_dev_t;
> #define __kernel_old_dev_t __kernel_old_dev_t
>
> +typedef long __kernel_time_t;
> +#define __kernel_time_t __kernel_time_t
> +
> +typedef long __kernel_clock_t;
> +#define __kernel_clock_t __kernel_clock_t
> +
> #include <asm-generic/posix_types.h>
>
> #endif /* _UAPI__ASM_AVR32_POSIX_TYPES_H */
Quickly looked over some of the other patches in the series, and they all
seem to add the same. Could this be generic, with the possibility for arch to
override?
--
mvh
Hans-Christian Egtvedt
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 19:32 ` Arnd Bergmann
@ 2014-05-13 20:35 ` Geert Uytterhoeven
2014-05-14 11:00 ` Arnd Bergmann
2014-05-14 21:33 ` John Stultz
1 sibling, 1 reply; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-13 20:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
Hi Arnd,
On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I think we have three categories:
Thanks for the list!
> a) interfaces that uses relative time_t/timespec/timeval:
> b) interfaces that don't make sense for times in the past:
> c) interfaces that require absolute times:
> - stat/lstat/fstatat/
> - utime/utimes/futimesat
>
> These absolutely have to use something better than time_t
> both in user space and in the kernel so we can deal with
> old files. A lot of file systems need to be fixed as well so
> we can actually store the times, regardless of whether we
> are running a 32 or 64 bit kernel.
So these are the ones we have to worry about.
It looks like they all involve I/O? Apart from the case of using block data
from the buffer cache, the 64-bit operations should disappear in the
actual I/O noise, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 04/25] avr32: Add 32 bit time_t and clock_t
2014-05-13 20:19 ` Hans-Christian Egtvedt
@ 2014-05-14 1:54 ` Ley Foon Tan
2014-05-14 7:44 ` Hans-Christian Egtvedt
0 siblings, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-14 1:54 UTC (permalink / raw)
To: Hans-Christian Egtvedt
Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, Haavard Skinnemoen
On Wed, May 14, 2014 at 4:19 AM, Hans-Christian Egtvedt
<egtvedt@samfundet.no> wrote:
> Around Tue 13 May 2014 17:02:49 +0800 or thereabout, Ley Foon Tan wrote:
>> Override time_t and clock_t in include/uapi/asm-generic.
>>
>> Signed-off-by: Ley Foon Tan <lftan@altera.com>
>
> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>
>
> Quickly looked over some of the other patches in the series, and they all
> seem to add the same. Could this be generic, with the possibility for arch to
> override?
In this patchset, the generic one will be 64 bit (long long). So, the
existing 32 bit users need to override this.
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 17/25] parisc: Add 32 bit time_t and clock_t
2014-05-13 20:17 ` Helge Deller
@ 2014-05-14 1:57 ` Ley Foon Tan
2014-05-15 0:34 ` H. Peter Anvin
1 sibling, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-14 1:57 UTC (permalink / raw)
To: Helge Deller
Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, James E.J. Bottomley,
linux-parisc
On Wed, May 14, 2014 at 4:17 AM, Helge Deller <deller@gmx.de> wrote:
> Hi Ley,
>
> On 05/13/2014 11:06 AM, Ley Foon Tan wrote:
>> Override time_t and clock_t in include/uapi/asm-generic.
>>
>> Signed-off-by: Ley Foon Tan <lftan@altera.com>
>> ---
>> arch/parisc/include/uapi/asm/posix_types.h | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/parisc/include/uapi/asm/posix_types.h b/arch/parisc/include/uapi/asm/posix_types.h
>> index b934425..21fcf1c 100644
>> --- a/arch/parisc/include/uapi/asm/posix_types.h
>> +++ b/arch/parisc/include/uapi/asm/posix_types.h
>> @@ -19,6 +19,14 @@ typedef int __kernel_suseconds_t;
>> typedef long long __kernel_off64_t;
>> typedef unsigned long long __kernel_ino64_t;
>>
>> +#ifndef CONFIG_64BIT
>
> We can't use CONFIG_64BIT for a userspace header file. Please use
> #if !defined(__LP64__)
> instead.
> But even then I'm not sure if it's all correct...
Okay, will change to this. Maybe can try compile and boot with this change.
Thanks.
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH 24/25] x86: Add 32 bit time_t and clock_t
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
` (24 preceding siblings ...)
2014-05-13 15:24 ` Christoph Hellwig
@ 2014-05-14 3:36 ` Ley Foon Tan
25 siblings, 0 replies; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-14 3:36 UTC (permalink / raw)
To: linux-arch, linux-kernel
Cc: Ley Foon Tan, lftan.linux, cltang, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86
Override time_t and clock_t in include/uapi/asm-generic.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
---
arch/x86/include/uapi/asm/posix_types_32.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/include/uapi/asm/posix_types_32.h b/arch/x86/include/uapi/asm/posix_types_32.h
index 8e52505..b6b7e3b 100644
--- a/arch/x86/include/uapi/asm/posix_types_32.h
+++ b/arch/x86/include/uapi/asm/posix_types_32.h
@@ -20,6 +20,12 @@ typedef unsigned short __kernel_gid_t;
typedef unsigned short __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
+typedef long __kernel_time_t;
+#define __kernel_time_t __kernel_time_t
+
+typedef long __kernel_clock_t;
+#define __kernel_clock_t __kernel_clock_t
+
#include <asm-generic/posix_types.h>
#endif /* _ASM_X86_POSIX_TYPES_32_H */
--
1.8.2.1
^ permalink raw reply related [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-13 10:22 ` James Hogan
@ 2014-05-14 3:47 ` H. Peter Anvin
2014-05-14 10:44 ` Geert Uytterhoeven
0 siblings, 1 reply; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-14 3:47 UTC (permalink / raw)
To: James Hogan, Ley Foon Tan
Cc: Linux-Arch, LKML, Chung-Lin Tang, Arnd Bergmann, Thomas Gleixner
On 05/13/2014 03:22 AM, James Hogan 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?
>
> Yeh, good point, that won't work.
How about:
#include <asm-generic/types/time32.h>
The asm-generic/types/ directory can be used for all kinds of type
templates, like int-ll64.h and the (now removed) former int-l64.h.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 04/25] avr32: Add 32 bit time_t and clock_t
2014-05-14 1:54 ` Ley Foon Tan
@ 2014-05-14 7:44 ` Hans-Christian Egtvedt
2014-05-14 21:39 ` H. Peter Anvin
0 siblings, 1 reply; 96+ messages in thread
From: Hans-Christian Egtvedt @ 2014-05-14 7:44 UTC (permalink / raw)
To: Ley Foon Tan; +Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, Haavard Skinnemoen
Around Wed 14 May 2014 09:54:25 +0800 or thereabout, Ley Foon Tan wrote:
> On Wed, May 14, 2014 at 4:19 AM, Hans-Christian Egtvedt <egtvedt@samfundet.no> wrote:
>> Around Tue 13 May 2014 17:02:49 +0800 or thereabout, Ley Foon Tan wrote:
>>> Override time_t and clock_t in include/uapi/asm-generic.
>>>
>>> Signed-off-by: Ley Foon Tan <lftan@altera.com>
>>
>> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>>
>> Quickly looked over some of the other patches in the series, and they all
>> seem to add the same. Could this be generic, with the possibility for arch to
>> override?
> In this patchset, the generic one will be 64 bit (long long). So, the
> existing 32 bit users need to override this.
Would it be wrong to use the architecture defined size, or does some 32-bit
architectures use 64-bit time types?
--
Hans-Christian Egtvedt
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 18:10 ` Arnd Bergmann
2014-05-13 18:24 ` Geert Uytterhoeven
@ 2014-05-14 10:13 ` Ley Foon Tan
2014-05-14 10:33 ` Arnd Bergmann
1 sibling, 1 reply; 96+ messages in thread
From: Ley Foon Tan @ 2014-05-14 10:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christoph Hellwig, Thomas Gleixner, Linux-Arch, linux-kernel,
Chung-Lin Tang
On Wed, May 14, 2014 at 2:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I've just spent two days looking at stuff that uses time_t inside
> of the kernel, to get a better idea of what we actually need to
> do to get provide new user interfaces for the existing architectures.
>
> My impression so far is that we're better off fixing it for the
> existing architectures first and then using the new interfaces
> exclusively on new ones, rather than changing over the ABI for
> all new architectures at this point, which would likely create
> yet another variant to maintain in the long run.
>
> Using 64-bit time_t on x32 is fine, because it's fast to operate
> in user space with 64-bit registers, and the kernel is 64-bit
> anyway. Inside of the kernel, we may get into trouble using
> a 64-bit time_t on 32-bit architectures because of the overhead
> in 64-bit math, e.g. all the timekeeping code that is based on
> timespec or some code paths in file systems and network code where
> we actually require division of time_t values.
> We clearly have to change that code in some for to deal with y2038,
> but 64-bit time_t may not be the best option. A lot of the
> in-kernel code can probably use ktime_t, which we can change
> to a different representation (e.g. 34 bit seconds) if needed,
> and all the code that is only interested in relative time
> (e.g. nanosleep) doesn't have to change at all.
Hi Arnd,
>From your comment above, can I assume we don't need this patchset any more?
Regards
Ley Foon
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 10:13 ` Ley Foon Tan
@ 2014-05-14 10:33 ` Arnd Bergmann
2014-05-14 21:04 ` H. Peter Anvin
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-14 10:33 UTC (permalink / raw)
To: Ley Foon Tan
Cc: Christoph Hellwig, Thomas Gleixner, Linux-Arch, linux-kernel,
Chung-Lin Tang, H. Peter Anvin
On Wednesday 14 May 2014 18:13:41 Ley Foon Tan wrote:
> On Wed, May 14, 2014 at 2:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I've just spent two days looking at stuff that uses time_t inside
> > of the kernel, to get a better idea of what we actually need to
> > do to get provide new user interfaces for the existing architectures.
> >
> > My impression so far is that we're better off fixing it for the
> > existing architectures first and then using the new interfaces
> > exclusively on new ones, rather than changing over the ABI for
> > all new architectures at this point, which would likely create
> > yet another variant to maintain in the long run.
> >
> > Using 64-bit time_t on x32 is fine, because it's fast to operate
> > in user space with 64-bit registers, and the kernel is 64-bit
> > anyway. Inside of the kernel, we may get into trouble using
> > a 64-bit time_t on 32-bit architectures because of the overhead
> > in 64-bit math, e.g. all the timekeeping code that is based on
> > timespec or some code paths in file systems and network code where
> > we actually require division of time_t values.
> > We clearly have to change that code in some for to deal with y2038,
> > but 64-bit time_t may not be the best option. A lot of the
> > in-kernel code can probably use ktime_t, which we can change
> > to a different representation (e.g. 34 bit seconds) if needed,
> > and all the code that is only interested in relative time
> > (e.g. nanosleep) doesn't have to change at all.
>
> Hi Arnd,
>
> From your comment above, can I assume we don't need this patchset any more?
I won't require it, but it's not just my decision to make.
Let's see what Peter Anvin and Thomas Gleixner think about it, as they
have argued strongly in favor of using 64-bit time_t for new architectures
in the past.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
2014-05-14 3:47 ` H. Peter Anvin
@ 2014-05-14 10:44 ` Geert Uytterhoeven
0 siblings, 0 replies; 96+ messages in thread
From: Geert Uytterhoeven @ 2014-05-14 10:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: James Hogan, Ley Foon Tan, Linux-Arch, LKML, Chung-Lin Tang,
Arnd Bergmann, Thomas Gleixner
On Wed, May 14, 2014 at 5:47 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/13/2014 03:22 AM, James Hogan 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?
>>
>> Yeh, good point, that won't work.
>
> How about:
>
> #include <asm-generic/types/time32.h>
>
> The asm-generic/types/ directory can be used for all kinds of type
> templates, like int-ll64.h and the (now removed) former int-l64.h.
That should more or less work. But better call it time-l.h, as time_t
should be 64-bit on 64-bit architectures. Else 32/64-bit architectures
still need an #ifdef.
Will time_t stay "long" (and not become "long long") on 64-bit?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 20:35 ` Geert Uytterhoeven
@ 2014-05-14 11:00 ` Arnd Bergmann
2014-05-14 12:21 ` Thomas Gleixner
2014-05-15 15:47 ` James Bottomley
0 siblings, 2 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-14 11:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
>
> On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I think we have three categories:
>
> Thanks for the list!
>
> > a) interfaces that uses relative time_t/timespec/timeval:
> > b) interfaces that don't make sense for times in the past:
>
> > c) interfaces that require absolute times:
> > - stat/lstat/fstatat/
> > - utime/utimes/futimesat
> >
> > These absolutely have to use something better than time_t
> > both in user space and in the kernel so we can deal with
> > old files. A lot of file systems need to be fixed as well so
> > we can actually store the times, regardless of whether we
> > are running a 32 or 64 bit kernel.
>
> So these are the ones we have to worry about.
> It looks like they all involve I/O? Apart from the case of using block data
> from the buffer cache, the 64-bit operations should disappear in the
> actual I/O noise, right?
Right. Also there have been proposals for a better 'stat' replacement
for years, which would solve half of the interface problem for the
file system interfaces.
However, we also need to find a solution for category b), I only put
them into a different category above because we can treat them
differently in the kernel. For instance, we could use ktime_t for
the kernel code in category b) and a new struct timespec64 for
the times in struct inode.
On the user interface side, using timespec64 would be a reasonable
choice for both categories, because we already have two implementations
of all those syscalls in order to handle 32-on-64 compat tasks,
and we could use the same set of syscall implementations for time64-on-32.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 11:00 ` Arnd Bergmann
@ 2014-05-14 12:21 ` Thomas Gleixner
2014-05-14 14:01 ` Arnd Bergmann
2014-05-15 15:47 ` James Bottomley
1 sibling, 1 reply; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-14 12:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Christoph Hellwig, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Wed, 14 May 2014, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> >
> > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > I think we have three categories:
> >
> > Thanks for the list!
> >
> > > a) interfaces that uses relative time_t/timespec/timeval:
> > > b) interfaces that don't make sense for times in the past:
> >
> > > c) interfaces that require absolute times:
> > > - stat/lstat/fstatat/
> > > - utime/utimes/futimesat
> > >
> > > These absolutely have to use something better than time_t
> > > both in user space and in the kernel so we can deal with
> > > old files. A lot of file systems need to be fixed as well so
> > > we can actually store the times, regardless of whether we
> > > are running a 32 or 64 bit kernel.
> >
> > So these are the ones we have to worry about.
> > It looks like they all involve I/O? Apart from the case of using block data
> > from the buffer cache, the 64-bit operations should disappear in the
> > actual I/O noise, right?
>
> Right. Also there have been proposals for a better 'stat' replacement
> for years, which would solve half of the interface problem for the
> file system interfaces.
>
> However, we also need to find a solution for category b), I only put
> them into a different category above because we can treat them
> differently in the kernel. For instance, we could use ktime_t for
> the kernel code in category b) and a new struct timespec64 for
> the times in struct inode.
> On the user interface side, using timespec64 would be a reasonable
> choice for both categories, because we already have two implementations
> of all those syscalls in order to handle 32-on-64 compat tasks,
> and we could use the same set of syscall implementations for time64-on-32.
So in the 32-on-64 case we'll have two compat variants:
SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
struct timespec __user *, utime, u32 __user *, uaddr2,
u32, val3)
COMPAT_SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
struct compat_timespec __user *, utime, u32 __user *, uaddr2,
u32, val3)
COMPAT_SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
struct timespec64 __user *, utime, u32 __user *, uaddr2,
u32, val3)
The native 64bit futex64 syscall is mapped to futex.
And for a 32bit kernel you have two
SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
struct timespec __user *, utime, u32 __user *, uaddr2,
u32, val3)
SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
struct timespec64 __user *, utime, u32 __user *, uaddr2,
u32, val3)
Fine with me, but we really need to discuss the timespec64 with user
space folks.
I'm curious, whether quite some code, like high frequency timestamps
wouldn't be better of with a strict 64 bit nanosecond granular time
represenation.
I often enough cursed timespec for clock_nanosleep on an absolute
timeline. I need to go through all that normalizing stuff instead of
just doing next_event += 500000;
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 12:21 ` Thomas Gleixner
@ 2014-05-14 14:01 ` Arnd Bergmann
2014-05-14 14:46 ` Thomas Gleixner
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-14 14:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Geert Uytterhoeven, Christoph Hellwig, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
>
> So in the 32-on-64 case we'll have two compat variants:
>
> SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> struct timespec __user *, utime, u32 __user *, uaddr2,
> u32, val3)
>
> COMPAT_SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> struct compat_timespec __user *, utime, u32 __user *, uaddr2,
> u32, val3)
>
> COMPAT_SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
> struct timespec64 __user *, utime, u32 __user *, uaddr2,
> u32, val3)
>
> The native 64bit futex64 syscall is mapped to futex.
I was actually hoping that we could map the compat futex64 to futex
as well here, since 64-bit timespec and compat timespec64 would be
the same structure.
> And for a 32bit kernel you have two
>
> SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> struct timespec __user *, utime, u32 __user *, uaddr2,
> u32, val3)
>
> SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
> struct timespec64 __user *, utime, u32 __user *, uaddr2,
> u32, val3)
And here, we could think about renaming the kernel internal symbols
so that we use the same two definitions as well, one for compat_timespec
and one for timespec64. Those are details we don't need to debate now.
> Fine with me, but we really need to discuss the timespec64 with user
> space folks.
Definitely.
> I'm curious, whether quite some code, like high frequency timestamps
> wouldn't be better of with a strict 64 bit nanosecond granular time
> represenation.
At least in the kernel, I think ktime_t is already the right type
to use on both 64-bit and 32-bit architectures as it can be slow to
extract the seconds portion of 64-bit nanoseconds on a 32-bit machine.
FWIW, 64-bit ns gives us 584 years worth of nanoseconds, which
means none of us or the people we know will be around before this
becomes a problem ;-)
For the user interface, we can decide which representation to use
for each syscall individually depending on the needs. We should just
not have to many different variants. I was going for timespec64
just because that would allow us to keep the 64-bit kernel ABI
unchanged.
> I often enough cursed timespec for clock_nanosleep on an absolute
> timeline. I need to go through all that normalizing stuff instead of
> just doing next_event += 500000;
And all user space needs to do it too.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 14:01 ` Arnd Bergmann
@ 2014-05-14 14:46 ` Thomas Gleixner
2014-05-14 15:48 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Thomas Gleixner @ 2014-05-14 14:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Christoph Hellwig, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Wed, 14 May 2014, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
> >
> > So in the 32-on-64 case we'll have two compat variants:
> >
> > SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> > struct timespec __user *, utime, u32 __user *, uaddr2,
> > u32, val3)
> >
> > COMPAT_SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> > struct compat_timespec __user *, utime, u32 __user *, uaddr2,
> > u32, val3)
> >
> > COMPAT_SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
> > struct timespec64 __user *, utime, u32 __user *, uaddr2,
> > u32, val3)
> >
> > The native 64bit futex64 syscall is mapped to futex.
>
> I was actually hoping that we could map the compat futex64 to futex
> as well here, since 64-bit timespec and compat timespec64 would be
> the same structure.
Right, that might work with this one, but not for anything which has a
pointer to a timespec and some other argument based on long.
> > I'm curious, whether quite some code, like high frequency timestamps
> > wouldn't be better of with a strict 64 bit nanosecond granular time
> > represenation.
>
> At least in the kernel, I think ktime_t is already the right type
> to use on both 64-bit and 32-bit architectures as it can be slow to
> extract the seconds portion of 64-bit nanoseconds on a 32-bit machine.
On some of them yes. On i386 the u64 nsec ktime_t variant is way more
efficient.
> FWIW, 64-bit ns gives us 584 years worth of nanoseconds, which
> means none of us or the people we know will be around before this
> becomes a problem ;-)
Indeed.
> For the user interface, we can decide which representation to use
> for each syscall individually depending on the needs. We should just
> not have to many different variants. I was going for timespec64
> just because that would allow us to keep the 64-bit kernel ABI
> unchanged.
Right. It's the way of least resistance.
If there are desires from user space to have a new format instead of
blindly timespec64 for certain syscalls, we should really think
discuss that on a case by case basis.
Thanks,
tglx
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 14:46 ` Thomas Gleixner
@ 2014-05-14 15:48 ` Arnd Bergmann
0 siblings, 0 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-14 15:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Geert Uytterhoeven, Christoph Hellwig, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Wednesday 14 May 2014 16:46:29 Thomas Gleixner wrote:
> On Wed, 14 May 2014, Arnd Bergmann wrote:
>
> > On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
> > >
> > > So in the 32-on-64 case we'll have two compat variants:
> > >
> > > SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> > > struct timespec __user *, utime, u32 __user *, uaddr2,
> > > u32, val3)
> > >
> > > COMPAT_SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> > > struct compat_timespec __user *, utime, u32 __user *, uaddr2,
> > > u32, val3)
> > >
> > > COMPAT_SYSCALL_DEFINE6(futex64, u32 __user *, uaddr, int, op, u32, val,
> > > struct timespec64 __user *, utime, u32 __user *, uaddr2,
> > > u32, val3)
> > >
> > > The native 64bit futex64 syscall is mapped to futex.
> >
> > I was actually hoping that we could map the compat futex64 to futex
> > as well here, since 64-bit timespec and compat timespec64 would be
> > the same structure.
>
> Right, that might work with this one, but not for anything which has a
> pointer to a timespec and some other argument based on long.
We'd have to look at each one individually of course, but out of this
list, I think it will work for most:
- getitimer/setitimer
- timer_settime/timer_gettime
- gettimeofday/settimeofday
- adjtimex
- clock_gettime/clock_settime/clock_adjtime
- time/stime
- sysv ipc (msg, sem, shm)
- fstatat (or the statx replacement once we get to that)
- futimesat
but not these ioctls:
- socket time stamps
- audio time stamps
- v4l time stamps
- input event time stamps
> > > I'm curious, whether quite some code, like high frequency timestamps
> > > wouldn't be better of with a strict 64 bit nanosecond granular time
> > > represenation.
> >
> > At least in the kernel, I think ktime_t is already the right type
> > to use on both 64-bit and 32-bit architectures as it can be slow to
> > extract the seconds portion of 64-bit nanoseconds on a 32-bit machine.
>
> On some of them yes. On i386 the u64 nsec ktime_t variant is way more
> efficient.
Ah, interesting. Do we have actual data for other architectures? If
it's much better on x86 and never much worse anywhere else, that
alone may be a reason to migrate the timestamp interfaces.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 10:33 ` Arnd Bergmann
@ 2014-05-14 21:04 ` H. Peter Anvin
0 siblings, 0 replies; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-14 21:04 UTC (permalink / raw)
To: Arnd Bergmann, Ley Foon Tan
Cc: Christoph Hellwig, Thomas Gleixner, Linux-Arch, linux-kernel,
Chung-Lin Tang
On 05/14/2014 03:33 AM, Arnd Bergmann wrote:
>>
>> Hi Arnd,
>>
>> From your comment above, can I assume we don't need this patchset any more?
>
> I won't require it, but it's not just my decision to make.
>
Linus has pushed extremely hard for it, and it *is* his decision to
make. If you want an authoritative answer I guess we need to wait until
Linus comes back.
> Let's see what Peter Anvin and Thomas Gleixner think about it, as they
> have argued strongly in favor of using 64-bit time_t for new architectures
> in the past.
I think it is downright looney to introduce a new ABI without a 64-bit
time_t at this point.
You are talking about a ktime_t; that is a kernel internal
implementation detail which can be changed later once the appropriate
kernel infrastructure is there, but we should make the change now to get
the external ABIs right, then we can microoptimize the kernel internal
implementation later.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-13 19:32 ` Arnd Bergmann
2014-05-13 20:35 ` Geert Uytterhoeven
@ 2014-05-14 21:33 ` John Stultz
2014-05-15 0:14 ` H. Peter Anvin
2014-05-15 11:08 ` Arnd Bergmann
1 sibling, 2 replies; 96+ messages in thread
From: John Stultz @ 2014-05-14 21:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Chung-Lin Tang
On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
>> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > Using 64-bit time_t on x32 is fine, because it's fast to operate
>> > in user space with 64-bit registers, and the kernel is 64-bit
>> > anyway. Inside of the kernel, we may get into trouble using
>> > a 64-bit time_t on 32-bit architectures because of the overhead
>> > in 64-bit math, e.g. all the timekeeping code that is based on
>> > timespec or some code paths in file systems and network code where
>> > we actually require division of time_t values.
>>
>> While going over time_t uses, have you found a pattern for use cases
>> involving division of time_t values in filesystem and networking code?
>
> In ipv4, we have multiple places doing this:
>
> icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC +
> tv.tv_nsec / NSEC_PER_MSEC);
>
> to calculate the miliseconds since midnight. For file systems, I
> found that FAT uses seconds/minutes/hours/days/month/year representation,
> which is a lot of divides, but that can probably be optimized and
> we need to handle years beyond 2038 anyway.
We can do some tricks for internal optimizations here if these are
critical. I'd be more concerned about userland divisions where moving
to a 64bit time_t would cause performance issues that we cannot help
optimize.
>> > We clearly have to change that code in some for to deal with y2038,
>> > but 64-bit time_t may not be the best option. A lot of the
>> > in-kernel code can probably use ktime_t, which we can change
>> > to a different representation (e.g. 34 bit seconds) if needed,
>> > and all the code that is only interested in relative time
>> > (e.g. nanosleep) doesn't have to change at all.
>>
>> Yeah. 32-bit uptimes should be good enough for everyone (don't quote
>> me on that), so adding a 64-bit offset when there's a need for absolute
>> time should be OK.
>
> I think we have three categories:
>
> a) interfaces that uses relative time_t/timespec/timeval:
> - nanosleep
> - select/pselect/poll/ppoll/epoll
> - getrusage
> - sched_rr_get_interval
> - sigtimedwait
> - clock_nanosleep
> - alarm
> - siginfo (rusage)
>
> These can stay compatible, but we'd have to use a different
> type if we change time_t.
So as a correction, at least clock_nanosleep can specify sleep times
using absolute time.
> b) interfaces that don't make sense for times in the past:
> - getitimer/setitimer
> - timer_settime/timer_gettime
> - gettimeofday/settimeofday
> - adjtimex
> - clock_gettime/clock_settime/clock_adjtime
> - time/stime
> - socket time stamps
> - audio time stamps
> - v4l time stamps
> - input event time stamps
> - sysv ipc (msg, sem, shm)
>
> Here, we are relatively free to change the start of the
> epoch in the kernel but convert to something else on the
> user space boundary. One possibility is to scale them to
> boot time and use ktime_t in the kernel.
I'm not sure I'm totally following this... Are you suggesting we keep
32bit time internally w/ some different offset but then pass to
userland a 64bit time_t? Or are you suggesting we change the abi to
move the epoch?
I think I'm with hpa in his recent mail in that the internal
representation is an optimization detail, and the bigger question is
do we use a 64bit time_t for future systems (possibly w/ a major ABI
break - with compat interface for existing 32bit applications), or do
we try to rev interfaces function by function to provide 2038 safe
versions which applications will have to be modified to use?
Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
applications to a 2038 safe ABI easier.
thanks
-john
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 04/25] avr32: Add 32 bit time_t and clock_t
2014-05-14 7:44 ` Hans-Christian Egtvedt
@ 2014-05-14 21:39 ` H. Peter Anvin
0 siblings, 0 replies; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-14 21:39 UTC (permalink / raw)
To: Hans-Christian Egtvedt, Ley Foon Tan
Cc: Linux-Arch, linux-kernel, Chung-Lin Tang, Haavard Skinnemoen
On 05/14/2014 12:44 AM, Hans-Christian Egtvedt wrote:
>> In this patchset, the generic one will be 64 bit (long long). So, the
>> existing 32 bit users need to override this.
>
> Would it be wrong to use the architecture defined size, or does some 32-bit
> architectures use 64-bit time types?
This is what we had done up until now, except for x32, *AND THAT IS
EXACTLY THE PROBLEM*. 2038 is only 24 years away.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 21:33 ` John Stultz
@ 2014-05-15 0:14 ` H. Peter Anvin
2014-05-15 3:32 ` Nicolas Pitre
2014-05-15 11:08 ` Arnd Bergmann
1 sibling, 1 reply; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-15 0:14 UTC (permalink / raw)
To: John Stultz, Arnd Bergmann
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Chung-Lin Tang
On 05/14/2014 02:33 PM, John Stultz wrote:
>
> We can do some tricks for internal optimizations here if these are
> critical. I'd be more concerned about userland divisions where moving
> to a 64bit time_t would cause performance issues that we cannot help
> optimize.
>
Honestly, the cost of not addressing the Y2038 problem in plenty of time
is going to be way, way, way, way more expensive than some additional
arithmetic.
As far as converting to calendar notation (e.g. the Gregorian calendar),
only the first division needs to be done with full time_t width.
Furthermore, since the divisor is known a priori, the compiler *should*
be able to do it as an inverse multiply.[1]
The remaining divisions are bounded, and a smart compiler should even
know that.
> I'm not sure I'm totally following this... Are you suggesting we keep
> 32bit time internally w/ some different offset but then pass to
> userland a 64bit time_t? Or are you suggesting we change the abi to
> move the epoch?
I think this makes sense as a way of emergency rescue of legacy ABIs --
similar to the windowing solution used to Y2K-rescue legacy systems.
Nonlegacy ABIs should just be designed correctly from the start.
> I think I'm with hpa in his recent mail in that the internal
> representation is an optimization detail, and the bigger question is146
> do we use a 64bit time_t for future systems (possibly w/ a major ABI
> break - with compat interface for existing 32bit applications), or do
> we try to rev interfaces function by function to provide 2038 safe
> versions which applications will have to be modified to use?
>
> Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
> applications to a 2038 safe ABI easier.
I obviously couldn't agree more.
-hpa
[1] Not entirely true: the highest possible divisor necessary when doing
Gregorian calendar calculations is 12_622_780_800 (0x2_f060_5980), the
number of seconds in each Gregorian 400-year cycle. Similarly, dividing
with 86400 first to separate time and date requires the date part of the
result to remain 64 bits until the next division. Thus, depending on
exactly how the calculations are partitioned it may be necessary to do
two 64-bit wide divisions; this can, however, be avoided with some care.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 17/25] parisc: Add 32 bit time_t and clock_t
2014-05-13 20:17 ` Helge Deller
2014-05-14 1:57 ` Ley Foon Tan
@ 2014-05-15 0:34 ` H. Peter Anvin
1 sibling, 0 replies; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-15 0:34 UTC (permalink / raw)
To: Helge Deller, Ley Foon Tan, linux-arch, linux-kernel
Cc: lftan.linux, cltang, James E.J. Bottomley, linux-parisc
On 05/13/2014 01:17 PM, Helge Deller wrote:
>
> We can't use CONFIG_64BIT for a userspace header file. Please use
> #if !defined(__LP64__)
> instead.
> But even then I'm not sure if it's all correct...
>
__u64 (or __s64) works fine in that case.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 0:14 ` H. Peter Anvin
@ 2014-05-15 3:32 ` Nicolas Pitre
0 siblings, 0 replies; 96+ messages in thread
From: Nicolas Pitre @ 2014-05-15 3:32 UTC (permalink / raw)
To: H. Peter Anvin
Cc: John Stultz, Arnd Bergmann, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Wed, 14 May 2014, H. Peter Anvin wrote:
> On 05/14/2014 02:33 PM, John Stultz wrote:
> >
> > We can do some tricks for internal optimizations here if these are
> > critical. I'd be more concerned about userland divisions where moving
> > to a 64bit time_t would cause performance issues that we cannot help
> > optimize.
> >
>
> Honestly, the cost of not addressing the Y2038 problem in plenty of time
> is going to be way, way, way, way more expensive than some additional
> arithmetic.
>
> As far as converting to calendar notation (e.g. the Gregorian calendar),
> only the first division needs to be done with full time_t width.
> Furthermore, since the divisor is known a priori, the compiler *should*
> be able to do it as an inverse multiply.[1]
The compiler is apparently not that smart. It does it already for 32 by
32 bit divisions, but not for 64 by 32 divisions. Fortunately, with
gcc-4 at least, constant propagation on long longs works well enough to
do it by hand. That's how I implemented do_div() for ARM years ago.
See arch/arm/include/asm/div64.h from line 65. The same could be
implemented for x86 and others.
Nicolas
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 21:33 ` John Stultz
2014-05-15 0:14 ` H. Peter Anvin
@ 2014-05-15 11:08 ` Arnd Bergmann
2014-05-15 11:18 ` Christoph Hellwig
` (2 more replies)
1 sibling, 3 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-15 11:08 UTC (permalink / raw)
To: John Stultz
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Chung-Lin Tang
On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
> >> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > Using 64-bit time_t on x32 is fine, because it's fast to operate
> >> > in user space with 64-bit registers, and the kernel is 64-bit
> >> > anyway. Inside of the kernel, we may get into trouble using
> >> > a 64-bit time_t on 32-bit architectures because of the overhead
> >> > in 64-bit math, e.g. all the timekeeping code that is based on
> >> > timespec or some code paths in file systems and network code where
> >> > we actually require division of time_t values.
> >>
> >> While going over time_t uses, have you found a pattern for use cases
> >> involving division of time_t values in filesystem and networking code?
> >
> > In ipv4, we have multiple places doing this:
> >
> > icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC +
> > tv.tv_nsec / NSEC_PER_MSEC);
> >
> > to calculate the miliseconds since midnight. For file systems, I
> > found that FAT uses seconds/minutes/hours/days/month/year representation,
> > which is a lot of divides, but that can probably be optimized and
> > we need to handle years beyond 2038 anyway.
>
> We can do some tricks for internal optimizations here if these are
> critical. I'd be more concerned about userland divisions where moving
> to a 64bit time_t would cause performance issues that we cannot help
> optimize.
Good point.
> >> > We clearly have to change that code in some for to deal with y2038,
> >> > but 64-bit time_t may not be the best option. A lot of the
> >> > in-kernel code can probably use ktime_t, which we can change
> >> > to a different representation (e.g. 34 bit seconds) if needed,
> >> > and all the code that is only interested in relative time
> >> > (e.g. nanosleep) doesn't have to change at all.
> >>
> >> Yeah. 32-bit uptimes should be good enough for everyone (don't quote
> >> me on that), so adding a 64-bit offset when there's a need for absolute
> >> time should be OK.
> >
> > I think we have three categories:
> >
> > a) interfaces that uses relative time_t/timespec/timeval:
> > - nanosleep
> > - select/pselect/poll/ppoll/epoll
> > - getrusage
> > - sched_rr_get_interval
> > - sigtimedwait
> > - clock_nanosleep
> > - alarm
> > - siginfo (rusage)
> >
> > These can stay compatible, but we'd have to use a different
> > type if we change time_t.
>
>
> So as a correction, at least clock_nanosleep can specify sleep times
> using absolute time.
Thanks.
> > b) interfaces that don't make sense for times in the past:
> > - getitimer/setitimer
> > - timer_settime/timer_gettime
> > - gettimeofday/settimeofday
> > - adjtimex
> > - clock_gettime/clock_settime/clock_adjtime
> > - time/stime
> > - socket time stamps
> > - audio time stamps
> > - v4l time stamps
> > - input event time stamps
> > - sysv ipc (msg, sem, shm)
> >
> > Here, we are relatively free to change the start of the
> > epoch in the kernel but convert to something else on the
> > user space boundary. One possibility is to scale them to
> > boot time and use ktime_t in the kernel.
>
> I'm not sure I'm totally following this... Are you suggesting we keep
> 32bit time internally w/ some different offset but then pass to
> userland a 64bit time_t? Or are you suggesting we change the abi to
> move the epoch?
What I meant is that regardless of what we decide for the ABI,
we can change the in-kernel representation in any way we like as
long as we can represent all dates that can occur during the runtime
of the kernel, i.e. we don't have to represent times between 1970 and
2014. This could mean one of many representations:
- time_t scaled forward by 44 years and/or made unsigned
- ktime_t scaled to boot time
- 64-bit nanoseconds starting at the epoch
- timespec64
> I think I'm with hpa in his recent mail in that the internal
> representation is an optimization detail, and the bigger question is
> do we use a 64bit time_t for future systems (possibly w/ a major ABI
> break - with compat interface for existing 32bit applications), or do
> we try to rev interfaces function by function to provide 2038 safe
> versions which applications will have to be modified to use?
>
> Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
> applications to a 2038 safe ABI easier.
I think there are two or three distinct problems:
a) We absolutely have to find a way to build a user space that
can survive 2038. This probably involves moving at least
time_t, timeval and timespec to use 64-bit representation.
b) We have to keep compatibility with existing user space running
on future kernels, which means at least x86, arm and a few
other 32-bit architectures (we can ignore some of the obsolete
ones if that helps us) need to provide syscall ABIs for both
32-bit time_t and whatever we use for the new syscalls and
ioctls. As Thomas said, for some interfaces this could mean
64-bit nanoseconds and for others it could be timespec64.
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.
For the kernel interface, I think we should deprecate any interfaces
using plain time_t and timeval, i.e. keep them around for existing
architectures (possibly with a kernel compile time option to disable
them so we are sure they don't leak out to new user space) and
provide kernel interfaces based on 64-bit timespec (or other
appropriate data structures for timestamps) for new architectures.
I see multiple ways of doing this, and I don't like any of them ;-)
1) rename all *time* types to *old_time*, and provide new ones
based on 64-bit time_t. We'd have to change them all at once,
and there would likely still be some build breakage with glibc.
The idea is that a libc built against old headers still works
fine on old and new kernels, and a libc built against new kernels
would automatically get 64-bit time but stop working on old
kernels. Also, any binaries built against old glibc wouldn't
work on new glibc, which is probably a killer.
Example:
-typedef long __kernel_time_t;
+typedef long __kernel_oldtime_t;
+typedef __s64 __kernel_time_t;
-struct timespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
+struct oldtimespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
+struct timespec { __s64 tv_sec; __s64 tv_nsec; };
-long sys_utime(char __user *filename, struct utimbuf __user *times);
-long sys_utimes(char __user *filename, struct timeval __user *utimes);
-long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
-long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
+long sys_oldutime(char __user *filename, struct oldutimbuf __user *times);
+long sys_oldutimes(char __user *filename, struct oldtimeval __user *utimes);
+long sys_oldfutimesat(int dfd, const char __user *filename, struct oldtimeval __user *utimes);
+long sys_oldutimensat(int dfd, const char __user *filename, struct oldtimespec __user *utimes, int flags);
+long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
-#define __NR_utimensat 88
-#define __NR_utimes 1037
-#define __NR_futimesat 1066
-#define __NR_utime 1063
+#define __NR_oldutimensat 88
+#define __NR_oldutimes 1037
+#define __NR_oldfutimesat 1066
+#define __NR_oldutime 1063
+#define __NR_utimensat 277 /* next free number for asm-generic/unistd.h */
2) leave the kernel time_t as 'long' and only introduce a new
struct timespec64,defined to be compatible with struct timespec on
64-bit architectures. For each syscall or ioctl that we need, come up
with a new one. Make the libc define its own time_t as 64-bit and use
the new syscalls instead of the old ones. This will allow a smooth
transition, but we might not be done with it before 2038.
Example:
typedef long __kernel_time_t;
struct timespec { __kernel_time_t tv_sec; long tv_nsec; };
+struct timespec64 { __s64 tv_sec; __s64 tv_nsec; };
+#ifdef __ARCH_WANT_32BIT_TIME
long sys_utime(char __user *filename, struct utimbuf __user *times);
long sys_utimes(char __user *filename, struct timeval __user *utimes);
long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
+#endif
+long sys_futimens64at(int dfd, const char __user *filename, struct timespec64 __user *utimes, int flags);
+#ifdef __ARCH_WANT_32BIT_TIME
#define __NR_utimensat 88
#define __NR_utimes 1037
#define __NR_futimesat 1066
#define __NR_utime 1063
+#endif
+#define __NR_futimens64at 277 /* next free number for asm-generic/unistd.h */
3) Make time_t 64-bit for new 32-bit architectures right away, and worry
about existing architectures separately. This will mean avoiding intentional
ABI changes for the new architectures later, at the cost of having fringe
architecture use an ABI that nobody else uses, likely more broken.
Example (as in the patch series under review):
#ifndef __kernel_time_t
#typedef __s64 __kernel_time_t
#endif
4) Allow combinations of the above approaches using #ifdef in the uabi
headers to let the libc decide at compile time which of the first two
it wants. At the binary level they are compatible. This is most flexible
but means we have to worry more about getting the corner cases right,
with code that is even harder to maintain.
Example:
#ifdef __libc_want_64bit_time
typedef long __kernel_oldtime_t;
typedef __s64 __kernel_time_t;
#else
typedef long __kernel_time_t;
typedef __s64 __kernel_time64_t;
#endif
#ifdef __libc_want_64bit_time
#define __NR_oldutimensat 88
#define __NR_futimensat 277
#else
#define __NR_utimensat 88
#define __NR_futimens64at 277
#endif
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 11:08 ` Arnd Bergmann
@ 2014-05-15 11:18 ` Christoph Hellwig
2014-05-15 17:11 ` Chung-Lin Tang
2014-05-15 17:12 ` Chung-Lin Tang
2 siblings, 0 replies; 96+ messages in thread
From: Christoph Hellwig @ 2014-05-15 11:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: John Stultz, Geert Uytterhoeven, Christoph Hellwig,
Thomas Gleixner, Ley Foon Tan, Linux-Arch, linux-kernel,
LeyFoon Tan, Chung-Lin Tang
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.
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-14 11:00 ` Arnd Bergmann
2014-05-14 12:21 ` Thomas Gleixner
@ 2014-05-15 15:47 ` James Bottomley
2014-05-15 16:36 ` Arnd Bergmann
1 sibling, 1 reply; 96+ messages in thread
From: James Bottomley @ 2014-05-15 15:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Chung-Lin Tang
On Wed, 2014-05-14 at 13:00 +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> >
> > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > I think we have three categories:
> >
> > Thanks for the list!
> >
> > > a) interfaces that uses relative time_t/timespec/timeval:
> > > b) interfaces that don't make sense for times in the past:
> >
> > > c) interfaces that require absolute times:
> > > - stat/lstat/fstatat/
> > > - utime/utimes/futimesat
> > >
> > > These absolutely have to use something better than time_t
> > > both in user space and in the kernel so we can deal with
> > > old files. A lot of file systems need to be fixed as well so
> > > we can actually store the times, regardless of whether we
> > > are running a 32 or 64 bit kernel.
> >
> > So these are the ones we have to worry about.
> > It looks like they all involve I/O? Apart from the case of using block data
> > from the buffer cache, the 64-bit operations should disappear in the
> > actual I/O noise, right?
>
> Right. Also there have been proposals for a better 'stat' replacement
> for years, which would solve half of the interface problem for the
> file system interfaces.
>
> However, we also need to find a solution for category b), I only put
> them into a different category above because we can treat them
> differently in the kernel. For instance, we could use ktime_t for
> the kernel code in category b) and a new struct timespec64 for
> the times in struct inode.
> On the user interface side, using timespec64 would be a reasonable
> choice for both categories, because we already have two implementations
> of all those syscalls in order to handle 32-on-64 compat tasks,
> and we could use the same set of syscall implementations for time64-on-32.
To step back a bit, is a 64 bit time_t actually a good solution on 32
bits? Paying a 64 bit penalty on every time operation does seem a bit
overkill. Most eventual uses are either monotonic counting or relative
addition/subtraction. If we added an additional 32 bit quantity called
epoch, this would increase once every 68 years. Within the kernel, we
could do intelligent interpolation about what the epoch is, so in 2039
if we get a low 32 bit time_t value, we assume epoch == 1, conversely if
we see a high one, we assume epoch == 0. We could add epoch on the end
of the syscalls and detect if it's not present and fill in an
interpolated value. Interfaces which truly want 64 bit time_t would get
it from epoch + 32 bit time_t.
James
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 15:47 ` James Bottomley
@ 2014-05-15 16:36 ` Arnd Bergmann
2014-05-15 21:07 ` One Thousand Gnomes
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-15 16:36 UTC (permalink / raw)
To: James Bottomley
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Chung-Lin Tang
On Thursday 15 May 2014 11:47:03 James Bottomley wrote:
> On Wed, 2014-05-14 at 13:00 +0200, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> > >
> > > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > I think we have three categories:
> > >
> > > Thanks for the list!
> > >
> > > > a) interfaces that uses relative time_t/timespec/timeval:
> > > > b) interfaces that don't make sense for times in the past:
> > >
> > > > c) interfaces that require absolute times:
> > > > - stat/lstat/fstatat/
> > > > - utime/utimes/futimesat
> > > >
> > > > These absolutely have to use something better than time_t
> > > > both in user space and in the kernel so we can deal with
> > > > old files. A lot of file systems need to be fixed as well so
> > > > we can actually store the times, regardless of whether we
> > > > are running a 32 or 64 bit kernel.
> > >
> > > So these are the ones we have to worry about.
> > > It looks like they all involve I/O? Apart from the case of using block data
> > > from the buffer cache, the 64-bit operations should disappear in the
> > > actual I/O noise, right?
> >
> > Right. Also there have been proposals for a better 'stat' replacement
> > for years, which would solve half of the interface problem for the
> > file system interfaces.
> >
> > However, we also need to find a solution for category b), I only put
> > them into a different category above because we can treat them
> > differently in the kernel. For instance, we could use ktime_t for
> > the kernel code in category b) and a new struct timespec64 for
> > the times in struct inode.
> > On the user interface side, using timespec64 would be a reasonable
> > choice for both categories, because we already have two implementations
> > of all those syscalls in order to handle 32-on-64 compat tasks,
> > and we could use the same set of syscall implementations for time64-on-32.
>
> To step back a bit, is a 64 bit time_t actually a good solution on 32
> bits? Paying a 64 bit penalty on every time operation does seem a bit
> overkill. Most eventual uses are either monotonic counting or relative
> addition/subtraction. If we added an additional 32 bit quantity called
> epoch, this would increase once every 68 years. Within the kernel, we
> could do intelligent interpolation about what the epoch is, so in 2039
> if we get a low 32 bit time_t value, we assume epoch == 1, conversely if
> we see a high one, we assume epoch == 0. We could add epoch on the end
> of the syscalls and detect if it's not present and fill in an
> interpolated value. Interfaces which truly want 64 bit time_t would get
> it from epoch + 32 bit time_t.
The main advantage that I see with 64-bit time_t is that a lot of user
space already works with it, because NetBSD and OpenBSD use this, and
all 64-bit Linux systems already work with this without changing the ABI.
If we want a POSIX extension to cover a new ABI, this would be the most
likely candidate.
For Linux-only interfaces, the 64-bit nanosecond timestamps seem like
a good alternative, and they would also speed up the 64-bit architectures
because we can skip the normalization.
As mentioned earlier, between kernel and user space it's probably best
to avoid time_t and timeval completely and just use timespec64 or some
other safe type, but there has to be a way to port user space that relies
on time_t or timespec.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 11:08 ` Arnd Bergmann
2014-05-15 11:18 ` Christoph Hellwig
@ 2014-05-15 17:11 ` Chung-Lin Tang
2014-05-15 17:12 ` Chung-Lin Tang
2 siblings, 0 replies; 96+ messages in thread
From: Chung-Lin Tang @ 2014-05-15 17:11 UTC (permalink / raw)
To: Arnd Bergmann, John Stultz
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan
On 2014/5/15 07:08 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
>> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
>>>> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> Using 64-bit time_t on x32 is fine, because it's fast to operate
>>>>> in user space with 64-bit registers, and the kernel is 64-bit
>>>>> anyway. Inside of the kernel, we may get into trouble using
>>>>> a 64-bit time_t on 32-bit architectures because of the overhead
>>>>> in 64-bit math, e.g. all the timekeeping code that is based on
>>>>> timespec or some code paths in file systems and network code where
>>>>> we actually require division of time_t values.
>>>>
>>>> While going over time_t uses, have you found a pattern for use cases
>>>> involving division of time_t values in filesystem and networking code?
>>>
>>> In ipv4, we have multiple places doing this:
>>>
>>> icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC +
>>> tv.tv_nsec / NSEC_PER_MSEC);
>>>
>>> to calculate the miliseconds since midnight. For file systems, I
>>> found that FAT uses seconds/minutes/hours/days/month/year representation,
>>> which is a lot of divides, but that can probably be optimized and
>>> we need to handle years beyond 2038 anyway.
>>
>> We can do some tricks for internal optimizations here if these are
>> critical. I'd be more concerned about userland divisions where moving
>> to a 64bit time_t would cause performance issues that we cannot help
>> optimize.
>
> Good point.
>
>>>>> We clearly have to change that code in some for to deal with y2038,
>>>>> but 64-bit time_t may not be the best option. A lot of the
>>>>> in-kernel code can probably use ktime_t, which we can change
>>>>> to a different representation (e.g. 34 bit seconds) if needed,
>>>>> and all the code that is only interested in relative time
>>>>> (e.g. nanosleep) doesn't have to change at all.
>>>>
>>>> Yeah. 32-bit uptimes should be good enough for everyone (don't quote
>>>> me on that), so adding a 64-bit offset when there's a need for absolute
>>>> time should be OK.
>>>
>>> I think we have three categories:
>>>
>>> a) interfaces that uses relative time_t/timespec/timeval:
>>> - nanosleep
>>> - select/pselect/poll/ppoll/epoll
>>> - getrusage
>>> - sched_rr_get_interval
>>> - sigtimedwait
>>> - clock_nanosleep
>>> - alarm
>>> - siginfo (rusage)
>>>
>>> These can stay compatible, but we'd have to use a different
>>> type if we change time_t.
>>
>>
>> So as a correction, at least clock_nanosleep can specify sleep times
>> using absolute time.
>
> Thanks.
>
>>> b) interfaces that don't make sense for times in the past:
>>> - getitimer/setitimer
>>> - timer_settime/timer_gettime
>>> - gettimeofday/settimeofday
>>> - adjtimex
>>> - clock_gettime/clock_settime/clock_adjtime
>>> - time/stime
>>> - socket time stamps
>>> - audio time stamps
>>> - v4l time stamps
>>> - input event time stamps
>>> - sysv ipc (msg, sem, shm)
>>>
>>> Here, we are relatively free to change the start of the
>>> epoch in the kernel but convert to something else on the
>>> user space boundary. One possibility is to scale them to
>>> boot time and use ktime_t in the kernel.
>>
>> I'm not sure I'm totally following this... Are you suggesting we keep
>> 32bit time internally w/ some different offset but then pass to
>> userland a 64bit time_t? Or are you suggesting we change the abi to
>> move the epoch?
>
> What I meant is that regardless of what we decide for the ABI,
> we can change the in-kernel representation in any way we like as
> long as we can represent all dates that can occur during the runtime
> of the kernel, i.e. we don't have to represent times between 1970 and
> 2014. This could mean one of many representations:
>
> - time_t scaled forward by 44 years and/or made unsigned
> - ktime_t scaled to boot time
> - 64-bit nanoseconds starting at the epoch
> - timespec64
>
>> I think I'm with hpa in his recent mail in that the internal
>> representation is an optimization detail, and the bigger question is
>> do we use a 64bit time_t for future systems (possibly w/ a major ABI
>> break - with compat interface for existing 32bit applications), or do
>> we try to rev interfaces function by function to provide 2038 safe
>> versions which applications will have to be modified to use?
>>
>> Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
>> applications to a 2038 safe ABI easier.
>
> I think there are two or three distinct problems:
>
> a) We absolutely have to find a way to build a user space that
> can survive 2038. This probably involves moving at least
> time_t, timeval and timespec to use 64-bit representation.
> b) We have to keep compatibility with existing user space running
> on future kernels, which means at least x86, arm and a few
> other 32-bit architectures (we can ignore some of the obsolete
> ones if that helps us) need to provide syscall ABIs for both
> 32-bit time_t and whatever we use for the new syscalls and
> ioctls. As Thomas said, for some interfaces this could mean
> 64-bit nanoseconds and for others it could be timespec64.
> 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.
glibc does version its exported symbols, so provided new/old syscalls
are both provided, haveing a new version of a routine (using 64-bit
time_t and new syscall interfaces) and the old compat routine co-exist
should be possible. Of course, old binaries may still not be saved when
2038 arrives.
(Adding Joseph to the CC, for more definitive comments)
Thanks,
Chung-Lin
> 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.
>
> For the kernel interface, I think we should deprecate any interfaces
> using plain time_t and timeval, i.e. keep them around for existing
> architectures (possibly with a kernel compile time option to disable
> them so we are sure they don't leak out to new user space) and
> provide kernel interfaces based on 64-bit timespec (or other
> appropriate data structures for timestamps) for new architectures.
>
> I see multiple ways of doing this, and I don't like any of them ;-)
>
> 1) rename all *time* types to *old_time*, and provide new ones
> based on 64-bit time_t. We'd have to change them all at once,
> and there would likely still be some build breakage with glibc.
> The idea is that a libc built against old headers still works
> fine on old and new kernels, and a libc built against new kernels
> would automatically get 64-bit time but stop working on old
> kernels. Also, any binaries built against old glibc wouldn't
> work on new glibc, which is probably a killer.
>
> Example:
>
> -typedef long __kernel_time_t;
> +typedef long __kernel_oldtime_t;
> +typedef __s64 __kernel_time_t;
> -struct timespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
> +struct oldtimespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
> +struct timespec { __s64 tv_sec; __s64 tv_nsec; };
>
> -long sys_utime(char __user *filename, struct utimbuf __user *times);
> -long sys_utimes(char __user *filename, struct timeval __user *utimes);
> -long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
> -long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
> +long sys_oldutime(char __user *filename, struct oldutimbuf __user *times);
> +long sys_oldutimes(char __user *filename, struct oldtimeval __user *utimes);
> +long sys_oldfutimesat(int dfd, const char __user *filename, struct oldtimeval __user *utimes);
> +long sys_oldutimensat(int dfd, const char __user *filename, struct oldtimespec __user *utimes, int flags);
>
> +long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
>
> -#define __NR_utimensat 88
> -#define __NR_utimes 1037
> -#define __NR_futimesat 1066
> -#define __NR_utime 1063
> +#define __NR_oldutimensat 88
> +#define __NR_oldutimes 1037
> +#define __NR_oldfutimesat 1066
> +#define __NR_oldutime 1063
>
> +#define __NR_utimensat 277 /* next free number for asm-generic/unistd.h */
>
> 2) leave the kernel time_t as 'long' and only introduce a new
> struct timespec64,defined to be compatible with struct timespec on
> 64-bit architectures. For each syscall or ioctl that we need, come up
> with a new one. Make the libc define its own time_t as 64-bit and use
> the new syscalls instead of the old ones. This will allow a smooth
> transition, but we might not be done with it before 2038.
>
> Example:
>
> typedef long __kernel_time_t;
> struct timespec { __kernel_time_t tv_sec; long tv_nsec; };
> +struct timespec64 { __s64 tv_sec; __s64 tv_nsec; };
>
> +#ifdef __ARCH_WANT_32BIT_TIME
> long sys_utime(char __user *filename, struct utimbuf __user *times);
> long sys_utimes(char __user *filename, struct timeval __user *utimes);
> long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
> long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
> +#endif
> +long sys_futimens64at(int dfd, const char __user *filename, struct timespec64 __user *utimes, int flags);
>
>
> +#ifdef __ARCH_WANT_32BIT_TIME
> #define __NR_utimensat 88
> #define __NR_utimes 1037
> #define __NR_futimesat 1066
> #define __NR_utime 1063
> +#endif
>
> +#define __NR_futimens64at 277 /* next free number for asm-generic/unistd.h */
>
> 3) Make time_t 64-bit for new 32-bit architectures right away, and worry
> about existing architectures separately. This will mean avoiding intentional
> ABI changes for the new architectures later, at the cost of having fringe
> architecture use an ABI that nobody else uses, likely more broken.
>
> Example (as in the patch series under review):
>
> #ifndef __kernel_time_t
> #typedef __s64 __kernel_time_t
> #endif
>
> 4) Allow combinations of the above approaches using #ifdef in the uabi
> headers to let the libc decide at compile time which of the first two
> it wants. At the binary level they are compatible. This is most flexible
> but means we have to worry more about getting the corner cases right,
> with code that is even harder to maintain.
>
> Example:
>
> #ifdef __libc_want_64bit_time
> typedef long __kernel_oldtime_t;
> typedef __s64 __kernel_time_t;
> #else
> typedef long __kernel_time_t;
> typedef __s64 __kernel_time64_t;
> #endif
>
> #ifdef __libc_want_64bit_time
> #define __NR_oldutimensat 88
> #define __NR_futimensat 277
> #else
> #define __NR_utimensat 88
> #define __NR_futimens64at 277
> #endif
>
> Arnd
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 11:08 ` Arnd Bergmann
2014-05-15 11:18 ` Christoph Hellwig
2014-05-15 17:11 ` Chung-Lin Tang
@ 2014-05-15 17:12 ` Chung-Lin Tang
2014-05-15 18:01 ` Joseph S. Myers
2 siblings, 1 reply; 96+ messages in thread
From: Chung-Lin Tang @ 2014-05-15 17:12 UTC (permalink / raw)
To: Arnd Bergmann, John Stultz
Cc: Geert Uytterhoeven, Christoph Hellwig, Thomas Gleixner,
Ley Foon Tan, Linux-Arch, linux-kernel, LeyFoon Tan,
Joseph S. Myers
On 2014/5/15 07:08 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
>> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
>>>> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>> Using 64-bit time_t on x32 is fine, because it's fast to operate
>>>>> in user space with 64-bit registers, and the kernel is 64-bit
>>>>> anyway. Inside of the kernel, we may get into trouble using
>>>>> a 64-bit time_t on 32-bit architectures because of the overhead
>>>>> in 64-bit math, e.g. all the timekeeping code that is based on
>>>>> timespec or some code paths in file systems and network code where
>>>>> we actually require division of time_t values.
>>>>
>>>> While going over time_t uses, have you found a pattern for use cases
>>>> involving division of time_t values in filesystem and networking code?
>>>
>>> In ipv4, we have multiple places doing this:
>>>
>>> icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC +
>>> tv.tv_nsec / NSEC_PER_MSEC);
>>>
>>> to calculate the miliseconds since midnight. For file systems, I
>>> found that FAT uses seconds/minutes/hours/days/month/year representation,
>>> which is a lot of divides, but that can probably be optimized and
>>> we need to handle years beyond 2038 anyway.
>>
>> We can do some tricks for internal optimizations here if these are
>> critical. I'd be more concerned about userland divisions where moving
>> to a 64bit time_t would cause performance issues that we cannot help
>> optimize.
>
> Good point.
>
>>>>> We clearly have to change that code in some for to deal with y2038,
>>>>> but 64-bit time_t may not be the best option. A lot of the
>>>>> in-kernel code can probably use ktime_t, which we can change
>>>>> to a different representation (e.g. 34 bit seconds) if needed,
>>>>> and all the code that is only interested in relative time
>>>>> (e.g. nanosleep) doesn't have to change at all.
>>>>
>>>> Yeah. 32-bit uptimes should be good enough for everyone (don't quote
>>>> me on that), so adding a 64-bit offset when there's a need for absolute
>>>> time should be OK.
>>>
>>> I think we have three categories:
>>>
>>> a) interfaces that uses relative time_t/timespec/timeval:
>>> - nanosleep
>>> - select/pselect/poll/ppoll/epoll
>>> - getrusage
>>> - sched_rr_get_interval
>>> - sigtimedwait
>>> - clock_nanosleep
>>> - alarm
>>> - siginfo (rusage)
>>>
>>> These can stay compatible, but we'd have to use a different
>>> type if we change time_t.
>>
>>
>> So as a correction, at least clock_nanosleep can specify sleep times
>> using absolute time.
>
> Thanks.
>
>>> b) interfaces that don't make sense for times in the past:
>>> - getitimer/setitimer
>>> - timer_settime/timer_gettime
>>> - gettimeofday/settimeofday
>>> - adjtimex
>>> - clock_gettime/clock_settime/clock_adjtime
>>> - time/stime
>>> - socket time stamps
>>> - audio time stamps
>>> - v4l time stamps
>>> - input event time stamps
>>> - sysv ipc (msg, sem, shm)
>>>
>>> Here, we are relatively free to change the start of the
>>> epoch in the kernel but convert to something else on the
>>> user space boundary. One possibility is to scale them to
>>> boot time and use ktime_t in the kernel.
>>
>> I'm not sure I'm totally following this... Are you suggesting we keep
>> 32bit time internally w/ some different offset but then pass to
>> userland a 64bit time_t? Or are you suggesting we change the abi to
>> move the epoch?
>
> What I meant is that regardless of what we decide for the ABI,
> we can change the in-kernel representation in any way we like as
> long as we can represent all dates that can occur during the runtime
> of the kernel, i.e. we don't have to represent times between 1970 and
> 2014. This could mean one of many representations:
>
> - time_t scaled forward by 44 years and/or made unsigned
> - ktime_t scaled to boot time
> - 64-bit nanoseconds starting at the epoch
> - timespec64
>
>> I think I'm with hpa in his recent mail in that the internal
>> representation is an optimization detail, and the bigger question is
>> do we use a 64bit time_t for future systems (possibly w/ a major ABI
>> break - with compat interface for existing 32bit applications), or do
>> we try to rev interfaces function by function to provide 2038 safe
>> versions which applications will have to be modified to use?
>>
>> Me, I'm a fan of moving time_t to 64bits, since it makes "porting"
>> applications to a 2038 safe ABI easier.
>
> I think there are two or three distinct problems:
>
> a) We absolutely have to find a way to build a user space that
> can survive 2038. This probably involves moving at least
> time_t, timeval and timespec to use 64-bit representation.
> b) We have to keep compatibility with existing user space running
> on future kernels, which means at least x86, arm and a few
> other 32-bit architectures (we can ignore some of the obsolete
> ones if that helps us) need to provide syscall ABIs for both
> 32-bit time_t and whatever we use for the new syscalls and
> ioctls. As Thomas said, for some interfaces this could mean
> 64-bit nanoseconds and for others it could be timespec64.
> 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.
glibc does version its exported symbols, so provided new/old syscalls
are both provided, haveing a new version of a routine (using 64-bit
time_t and new syscall interfaces) and the old compat routine co-exist
should be possible. Of course, old binaries may still not be saved when
2038 arrives.
(Adding Joseph to the CC, for more definitive comments)
Thanks,
Chung-Lin
> 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.
>
> For the kernel interface, I think we should deprecate any interfaces
> using plain time_t and timeval, i.e. keep them around for existing
> architectures (possibly with a kernel compile time option to disable
> them so we are sure they don't leak out to new user space) and
> provide kernel interfaces based on 64-bit timespec (or other
> appropriate data structures for timestamps) for new architectures.
>
> I see multiple ways of doing this, and I don't like any of them ;-)
>
> 1) rename all *time* types to *old_time*, and provide new ones
> based on 64-bit time_t. We'd have to change them all at once,
> and there would likely still be some build breakage with glibc.
> The idea is that a libc built against old headers still works
> fine on old and new kernels, and a libc built against new kernels
> would automatically get 64-bit time but stop working on old
> kernels. Also, any binaries built against old glibc wouldn't
> work on new glibc, which is probably a killer.
>
> Example:
>
> -typedef long __kernel_time_t;
> +typedef long __kernel_oldtime_t;
> +typedef __s64 __kernel_time_t;
> -struct timespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
> +struct oldtimespec { __kernel_oldtime_t tv_sec; long tv_nsec; };
> +struct timespec { __s64 tv_sec; __s64 tv_nsec; };
>
> -long sys_utime(char __user *filename, struct utimbuf __user *times);
> -long sys_utimes(char __user *filename, struct timeval __user *utimes);
> -long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
> -long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
> +long sys_oldutime(char __user *filename, struct oldutimbuf __user *times);
> +long sys_oldutimes(char __user *filename, struct oldtimeval __user *utimes);
> +long sys_oldfutimesat(int dfd, const char __user *filename, struct oldtimeval __user *utimes);
> +long sys_oldutimensat(int dfd, const char __user *filename, struct oldtimespec __user *utimes, int flags);
>
> +long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
>
> -#define __NR_utimensat 88
> -#define __NR_utimes 1037
> -#define __NR_futimesat 1066
> -#define __NR_utime 1063
> +#define __NR_oldutimensat 88
> +#define __NR_oldutimes 1037
> +#define __NR_oldfutimesat 1066
> +#define __NR_oldutime 1063
>
> +#define __NR_utimensat 277 /* next free number for asm-generic/unistd.h */
>
> 2) leave the kernel time_t as 'long' and only introduce a new
> struct timespec64,defined to be compatible with struct timespec on
> 64-bit architectures. For each syscall or ioctl that we need, come up
> with a new one. Make the libc define its own time_t as 64-bit and use
> the new syscalls instead of the old ones. This will allow a smooth
> transition, but we might not be done with it before 2038.
>
> Example:
>
> typedef long __kernel_time_t;
> struct timespec { __kernel_time_t tv_sec; long tv_nsec; };
> +struct timespec64 { __s64 tv_sec; __s64 tv_nsec; };
>
> +#ifdef __ARCH_WANT_32BIT_TIME
> long sys_utime(char __user *filename, struct utimbuf __user *times);
> long sys_utimes(char __user *filename, struct timeval __user *utimes);
> long sys_futimesat(int dfd, const char __user *filename, struct timeval __user *utimes);
> long sys_utimensat(int dfd, const char __user *filename, struct timespec __user *utimes, int flags);
> +#endif
> +long sys_futimens64at(int dfd, const char __user *filename, struct timespec64 __user *utimes, int flags);
>
>
> +#ifdef __ARCH_WANT_32BIT_TIME
> #define __NR_utimensat 88
> #define __NR_utimes 1037
> #define __NR_futimesat 1066
> #define __NR_utime 1063
> +#endif
>
> +#define __NR_futimens64at 277 /* next free number for asm-generic/unistd.h */
>
> 3) Make time_t 64-bit for new 32-bit architectures right away, and worry
> about existing architectures separately. This will mean avoiding intentional
> ABI changes for the new architectures later, at the cost of having fringe
> architecture use an ABI that nobody else uses, likely more broken.
>
> Example (as in the patch series under review):
>
> #ifndef __kernel_time_t
> #typedef __s64 __kernel_time_t
> #endif
>
> 4) Allow combinations of the above approaches using #ifdef in the uabi
> headers to let the libc decide at compile time which of the first two
> it wants. At the binary level they are compatible. This is most flexible
> but means we have to worry more about getting the corner cases right,
> with code that is even harder to maintain.
>
> Example:
>
> #ifdef __libc_want_64bit_time
> typedef long __kernel_oldtime_t;
> typedef __s64 __kernel_time_t;
> #else
> typedef long __kernel_time_t;
> typedef __s64 __kernel_time64_t;
> #endif
>
> #ifdef __libc_want_64bit_time
> #define __NR_oldutimensat 88
> #define __NR_futimensat 277
> #else
> #define __NR_utimensat 88
> #define __NR_futimens64at 277
> #endif
>
> Arnd
>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 17:12 ` Chung-Lin Tang
@ 2014-05-15 18:01 ` Joseph S. Myers
2014-05-15 19:18 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-15 18:01 UTC (permalink / raw)
To: Chung-Lin Tang
Cc: Arnd Bergmann, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thu, 15 May 2014, Chung-Lin Tang 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.
>
> glibc does version its exported symbols, so provided new/old syscalls
> are both provided, haveing a new version of a routine (using 64-bit
> time_t and new syscall interfaces) and the old compat routine co-exist
> should be possible. Of course, old binaries may still not be saved when
> 2038 arrives.
You could do it with symbol versioning, though my guess would be that it
would be natural to provide _TIME_BITS like _FILE_OFFSET_BITS (with the
combination _TIME_BITS=64, _FILE_OFFSET_BITS=32 not being supported at
all) and then later transition the default. (Discussion of the
possibility of moving the default to _FILE_OFFSET_BITS=64 suggested that
in practice most libraries in distributions where this affects the ABI are
already built that way, though noone has followed up on that discussion to
try to reach a consensus that we have enough evidence to change the
default now. There are a couple of issues with the way
_FILE_OFFSET_BITS=64 is implemented that should be avoided in any
implementation of _TIME_BITS=64: (a) _FILE_OFFSET_BITS=64 maps functions
to corresponding *64 functions in the user's namespace, when it should use
reserved-namespace names; (b) it's not a no-op for 64-bit platforms - it
still remaps function names and types. So _TIME_BITS=64 should only map
to reserved-namespace names, and not do any remapping at all on platforms
where time_t is already 64-bit.)
Obviously 64-bit time_t syscalls would be an appropriately narrow set of
syscalls like those in the generic ABI (so glibc would implement stat for
_TIME_BITS=64 using fstatat64_time64 or whatever the syscall is called,
just as the stat functions for generic ABI architectures are implemented
with newfstatat / fstatat64 rather than lots of separate syscalls.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 18:01 ` Joseph S. Myers
@ 2014-05-15 19:18 ` Arnd Bergmann
2014-05-15 20:10 ` Joseph S. Myers
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-15 19:18 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thursday 15 May 2014 18:01:37 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Chung-Lin Tang 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.
> >
> > glibc does version its exported symbols, so provided new/old syscalls
> > are both provided, haveing a new version of a routine (using 64-bit
> > time_t and new syscall interfaces) and the old compat routine co-exist
> > should be possible. Of course, old binaries may still not be saved when
> > 2038 arrives.
How would that work for ioctl? There are a lot of device drivers that
have data structure with time_t or struct timespec in them.
> You could do it with symbol versioning, though my guess would be that it
> would be natural to provide _TIME_BITS like _FILE_OFFSET_BITS (with the
> combination _TIME_BITS=64, _FILE_OFFSET_BITS=32 not being supported at
> all) and then later transition the default. (Discussion of the
> possibility of moving the default to _FILE_OFFSET_BITS=64 suggested that
> in practice most libraries in distributions where this affects the ABI are
> already built that way, though noone has followed up on that discussion to
> try to reach a consensus that we have enough evidence to change the
> default now. There are a couple of issues with the way
> _FILE_OFFSET_BITS=64 is implemented that should be avoided in any
> implementation of _TIME_BITS=64: (a) _FILE_OFFSET_BITS=64 maps functions
> to corresponding *64 functions in the user's namespace, when it should use
> reserved-namespace names; (b) it's not a no-op for 64-bit platforms - it
> still remaps function names and types. So _TIME_BITS=64 should only map
> to reserved-namespace names, and not do any remapping at all on platforms
> where time_t is already 64-bit.)
Earlier in the thread there seemed to be a rough consensus that
_TIME_BITS=64 wouldn't be a good idea because we wouldn't get everything
changed to use it. For _FILE_OFFSET_BITS=64 that's ok because most
user space doesn't ever want to deal with large files.
Can you elaborate on how the switch to the new default would work?
If it's easy, why hasn't it been done for _FILE_OFFSET_BITS already
and what's stopping us from changing the default as soon as the interfaces
are there? If it's hard, what would need to happen before the default
time_t can be set?
> Obviously 64-bit time_t syscalls would be an appropriately narrow set of
> syscalls like those in the generic ABI (so glibc would implement stat for
> _TIME_BITS=64 using fstatat64_time64 or whatever the syscall is called,
> just as the stat functions for generic ABI architectures are implemented
> with newfstatat / fstatat64 rather than lots of separate syscalls.
This assumes that we'd leave the kernel time_t/timespec/timeval using 'long'
and introduce a new timespec64 using a signed 64-bit type, rather than
changing the kernel headers to the new syscalls and data structures with
new names for the existing ones, right?
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 19:18 ` Arnd Bergmann
@ 2014-05-15 20:10 ` Joseph S. Myers
2014-05-15 20:38 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-15 20:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thu, 15 May 2014, Arnd Bergmann wrote:
> Earlier in the thread there seemed to be a rough consensus that
> _TIME_BITS=64 wouldn't be a good idea because we wouldn't get everything
> changed to use it. For _FILE_OFFSET_BITS=64 that's ok because most
> user space doesn't ever want to deal with large files.
Well, I'm coming into this in the middle since it isn't on linux-api and
noone has tried to work out on libc-alpha what things should look like
from the glibc side. _TIME_BITS seemed to make sense when I thought about
this previously, however.
> Can you elaborate on how the switch to the new default would work?
At some appropriate release (probably after _TIME_BITS=64 is widely used
in distributions), the glibc headers would change so that _TIME_BITS=64 is
the default and _TIME_BITS=32 can be set to get the old interfaces. At
some later point _TIME_BITS=32 API support might be removed, leaving the
old symbols as compat symbols for existing binaries.
> If it's easy, why hasn't it been done for _FILE_OFFSET_BITS already
> and what's stopping us from changing the default as soon as the interfaces
> are there? If it's hard, what would need to happen before the default
> time_t can be set?
The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to
building libraries that way so a glibc change to the default wouldn't
cause issues for other libraries' ABIs) has gradually been done. The
discussion in March on libc-alpha about changing the default tailed off.
This is something that needs someone to take the lead with a *careful and
detailed analysis of the information from the previous discussion* in
order to present a properly reasoned proposal for a change to the default
- not scattergun patches, not patches with brief or no analysis of the
environment in which glibc is used, not dismissing concerns, but a
properly reasoned argument for why the change should be made, along with
details of how distributions can determine whether ABI issues would arise
from rebuilding a particular library against newer glibc.
> > Obviously 64-bit time_t syscalls would be an appropriately narrow set of
> > syscalls like those in the generic ABI (so glibc would implement stat for
> > _TIME_BITS=64 using fstatat64_time64 or whatever the syscall is called,
> > just as the stat functions for generic ABI architectures are implemented
> > with newfstatat / fstatat64 rather than lots of separate syscalls.
>
> This assumes that we'd leave the kernel time_t/timespec/timeval using 'long'
> and introduce a new timespec64 using a signed 64-bit type, rather than
> changing the kernel headers to the new syscalls and data structures with
> new names for the existing ones, right?
Yes. I consider it simply common sense that new kernel headers should
continue to work with much older glibc, meaning that the API (syscall
names etc.) presented by the headers from headers_install should not
change incompatibly.
(64-bit type only for time_t, of course. There's no need for a 64-bit
type for nanoseconds and tv_nsec is explicitly "long" in POSIX, meaning
that if the kernel uses a 64-bit type for nanoseconds on systems where
"long" is 32-bit in userspace, either it needs to treat the high word as
padding or glibc needs to wrap all interfaces passing a struct timespec
into the kernel so they clear the padding field. There's even less need
for a 64-bit type for microseconds.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 20:10 ` Joseph S. Myers
@ 2014-05-15 20:38 ` Arnd Bergmann
2014-05-15 21:05 ` Joseph S. Myers
2014-05-16 23:11 ` H. Peter Anvin
0 siblings, 2 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-15 20:38 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thursday 15 May 2014 20:10:05 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Arnd Bergmann wrote:
>
> > Earlier in the thread there seemed to be a rough consensus that
> > _TIME_BITS=64 wouldn't be a good idea because we wouldn't get everything
> > changed to use it. For _FILE_OFFSET_BITS=64 that's ok because most
> > user space doesn't ever want to deal with large files.
>
> Well, I'm coming into this in the middle since it isn't on linux-api and
> noone has tried to work out on libc-alpha what things should look like
> from the glibc side. _TIME_BITS seemed to make sense when I thought about
> this previously, however.
>
> > Can you elaborate on how the switch to the new default would work?
>
> At some appropriate release (probably after _TIME_BITS=64 is widely used
> in distributions), the glibc headers would change so that _TIME_BITS=64 is
> the default and _TIME_BITS=32 can be set to get the old interfaces. At
> some later point _TIME_BITS=32 API support might be removed, leaving the
> old symbols as compat symbols for existing binaries.
Ok.
> > If it's easy, why hasn't it been done for _FILE_OFFSET_BITS already
> > and what's stopping us from changing the default as soon as the interfaces
> > are there? If it's hard, what would need to happen before the default
> > time_t can be set?
>
> The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to
> building libraries that way so a glibc change to the default wouldn't
> cause issues for other libraries' ABIs) has gradually been done. The
> discussion in March on libc-alpha about changing the default tailed off.
> This is something that needs someone to take the lead with a *careful and
> detailed analysis of the information from the previous discussion* in
> order to present a properly reasoned proposal for a change to the default
> - not scattergun patches, not patches with brief or no analysis of the
> environment in which glibc is used, not dismissing concerns, but a
> properly reasoned argument for why the change should be made, along with
> details of how distributions can determine whether ABI issues would arise
> from rebuilding a particular library against newer glibc.
Ok, I see. I wasn't aware that distributions actually set _FILE_OFFSET_BITS
globally for building packages. I guess the effect (from the distro point
of view) of that is similar to having a configure option when building glibc
as I expected to be the normal way to do it.
> > > Obviously 64-bit time_t syscalls would be an appropriately narrow set of
> > > syscalls like those in the generic ABI (so glibc would implement stat for
> > > _TIME_BITS=64 using fstatat64_time64 or whatever the syscall is called,
> > > just as the stat functions for generic ABI architectures are implemented
> > > with newfstatat / fstatat64 rather than lots of separate syscalls.
> >
> > This assumes that we'd leave the kernel time_t/timespec/timeval using 'long'
> > and introduce a new timespec64 using a signed 64-bit type, rather than
> > changing the kernel headers to the new syscalls and data structures with
> > new names for the existing ones, right?
>
> Yes. I consider it simply common sense that new kernel headers should
> continue to work with much older glibc, meaning that the API (syscall
> names etc.) presented by the headers from headers_install should not
> change incompatibly.
Right. we have done it both ways in the past, but it seems that renaming
syscalls hasn't been done in some time. I can only find definitions for
oldfstat, oldlstat, oldolduname, olduname, oldumount, vm86old and oldwait4.
It's possible they all predate libc6.
> (64-bit type only for time_t, of course. There's no need for a 64-bit
> type for nanoseconds and tv_nsec is explicitly "long" in POSIX, meaning
> that if the kernel uses a 64-bit type for nanoseconds on systems where
> "long" is 32-bit in userspace, either it needs to treat the high word as
> padding or glibc needs to wrap all interfaces passing a struct timespec
> into the kernel so they clear the padding field. There's even less need
> for a 64-bit type for microseconds.)
For practical purposes in the kernel, we may still want to use 64-bit
nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
with the native type on 64-bit kernels, thus complicating the syscall
emulation layer.
I don't know why timespec on x32 uses 'long tv_nsec', it does seem
problematic.
What could work is a type that has explicit padding:
struct timespec {
__s64 tv_sec;
#ifdef BIG_ENDIAN_32BIT
u32 __pad;
#endif
long tv_nsec;
#ifdef LITTLE_ENDIAN_32BIT
u32 __pad;
#endif
};
For timeval, I think we don't care about the padding, because we wouldn't
use it on new interfaces when the kernel uses nanosecond resolution
internally.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 20:38 ` Arnd Bergmann
@ 2014-05-15 21:05 ` Joseph S. Myers
2014-05-19 8:08 ` Arnd Bergmann
2014-05-16 23:11 ` H. Peter Anvin
1 sibling, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-15 21:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thu, 15 May 2014, Arnd Bergmann wrote:
> > The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to
> > building libraries that way so a glibc change to the default wouldn't
> > cause issues for other libraries' ABIs) has gradually been done. The
> > discussion in March on libc-alpha about changing the default tailed off.
> > This is something that needs someone to take the lead with a *careful and
> > detailed analysis of the information from the previous discussion* in
> > order to present a properly reasoned proposal for a change to the default
> > - not scattergun patches, not patches with brief or no analysis of the
> > environment in which glibc is used, not dismissing concerns, but a
> > properly reasoned argument for why the change should be made, along with
> > details of how distributions can determine whether ABI issues would arise
> > from rebuilding a particular library against newer glibc.
>
> Ok, I see. I wasn't aware that distributions actually set _FILE_OFFSET_BITS
> globally for building packages. I guess the effect (from the distro point
> of view) of that is similar to having a configure option when building glibc
> as I expected to be the normal way to do it.
I'm not sure they set it globally (modulo the suggestion in that recent
thread that Gentoo might try changing the default and seeing what breaks)
- but it at least seems to be set for most libraries for which it affects
the ABI (whether upstream or by the distributions), based on the sample
Paul Eggert looked at
<https://sourceware.org/ml/libc-alpha/2014-03/msg00351.html> (which is an
important piece of evidence that a change to the default in glibc wouldn't
be dumping a large problem on distributors regarding the ABIs of many
widely-used libraries).
> I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> problematic.
Yes, we have a glibc bug
<https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
"long") being nonconforming, but without the kernel treating upper bits as
padding, fixing glibc requires wrappers that copy the value and clear the
upper bits.
> What could work is a type that has explicit padding:
>
> struct timespec {
> __s64 tv_sec;
> #ifdef BIG_ENDIAN_32BIT
> u32 __pad;
> #endif
> long tv_nsec;
> #ifdef LITTLE_ENDIAN_32BIT
> u32 __pad;
> #endif
> };
Yes. That's fine for POSIX (and I think x32 should move to such a
definition, though for glibc there would still be the issue of
compatibility with existing kernels).
> For timeval, I think we don't care about the padding, because we wouldn't
> use it on new interfaces when the kernel uses nanosecond resolution
> internally.
Indeed - I haven't checked, but hopefully none of the asm-generic
interfaces use timeval (and I was suggesting that only the interfaces
present in asm-generic should be duplicated for 64-bit time_t).
(You also mentioned ioctls. All affected ioctls would need new variants
unless you have a new variant of the ioctl syscall itself. Logically I
suppose _TIME_BITS=64 should then map the generic version of an ioctl to
the 64-bit time_t version so applications don't need to change beyond
defining _TIME_BITS=64, though I don't know if there's any precedent for
doing that sort of thing for definitions in kernel headers rather than
glibc's headers.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 16:36 ` Arnd Bergmann
@ 2014-05-15 21:07 ` One Thousand Gnomes
2014-05-16 7:48 ` Christoph Hellwig
0 siblings, 1 reply; 96+ messages in thread
From: One Thousand Gnomes @ 2014-05-15 21:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: James Bottomley, Geert Uytterhoeven, Christoph Hellwig,
Thomas Gleixner, Ley Foon Tan, Linux-Arch, linux-kernel,
LeyFoon Tan, Chung-Lin Tang
> > could do intelligent interpolation about what the epoch is, so in 2039
> > if we get a low 32 bit time_t value, we assume epoch == 1, conversely if
> > we see a high one, we assume epoch == 0. We could add epoch on the end
> > of the syscalls and detect if it's not present and fill in an
> > interpolated value. Interfaces which truly want 64 bit time_t would get
> > it from epoch + 32 bit time_t.
True sort of for the kernel (except you've got problems with file system
compatibility and I believe stuff like NFS and that fact some file
systems just break).
> The main advantage that I see with 64-bit time_t is that a lot of user
> space already works with it, because NetBSD and OpenBSD use this, and
> all 64-bit Linux systems already work with this without changing the ABI.
> If we want a POSIX extension to cover a new ABI, this would be the most
> likely candidate.
The main advantage IMHO of just using 64bit on 32bit boxes is getting it
right. I'd go so far as to consider changing userspace time_t to be a
struct. Yes it'll break lots of code but at least you'll know about it.
(and for some other systems like 2BSD it's probably the least of evils
because there isn't a 64bit type in the compiler!)
> As mentioned earlier, between kernel and user space it's probably best
> to avoid time_t and timeval completely and just use timespec64 or some
> other safe type, but there has to be a way to port user space that relies
> on time_t or timespec.
This I think is bang on. We've already got lots of cases where we can't
shoehorn useful info into syscalls due to time_t, including stuff like
exposing accurate stamps in stat(). On an 8MHz 68000 not much happened in
the same second, on a 32 core x86 it's a bit different.
Alan
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 21:07 ` One Thousand Gnomes
@ 2014-05-16 7:48 ` Christoph Hellwig
2014-05-16 23:06 ` H. Peter Anvin
0 siblings, 1 reply; 96+ messages in thread
From: Christoph Hellwig @ 2014-05-16 7:48 UTC (permalink / raw)
To: One Thousand Gnomes
Cc: Arnd Bergmann, James Bottomley, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan, Chung-Lin Tang
On Thu, May 15, 2014 at 10:07:17PM +0100, One Thousand Gnomes wrote:
> True sort of for the kernel (except you've got problems with file system
> compatibility and I believe stuff like NFS and that fact some file
> systems just break).
modern filesystems including NFS don't use anything that corresponds to
a time_t on disk or on the wire, so we'd just need to adjust the few
places the conert time representations.
> > The main advantage that I see with 64-bit time_t is that a lot of user
> > space already works with it, because NetBSD and OpenBSD use this, and
> > all 64-bit Linux systems already work with this without changing the ABI.
> > If we want a POSIX extension to cover a new ABI, this would be the most
> > likely candidate.
>
> The main advantage IMHO of just using 64bit on 32bit boxes is getting it
> right. I'd go so far as to consider changing userspace time_t to be a
> struct. Yes it'll break lots of code but at least you'll know about it.
I think we're attacking that from the wrong angle. We'll need to work
with the glibc and other libc folks to what can be implemented as the
library API/ABI and then ensure the kernel provides proper support for
it.
Chaning the size of time_t in the library seems like the only feasible
approach that keeps existing programs compatible. If we support this
with a time64_, a shifted epoch or structures at the kernel ABI is a
question of balaning what libc needs and what we can use efficiently
internally.
> > As mentioned earlier, between kernel and user space it's probably best
> > to avoid time_t and timeval completely and just use timespec64 or some
> > other safe type, but there has to be a way to port user space that relies
> > on time_t or timespec.
>
> This I think is bang on. We've already got lots of cases where we can't
> shoehorn useful info into syscalls due to time_t, including stuff like
> exposing accurate stamps in stat(). On an 8MHz 68000 not much happened in
> the same second, on a 32 core x86 it's a bit different.
The stat(64) syscall already has stopped time_t for a long time:
struct stat64 {
...
int st_atime; /* Time of last access. */
unsigned int st_atime_nsec;
int st_mtime; /* Time of last modification. */
unsigned int st_mtime_nsec;
int st_ctime; /* Time of last status change. */
unsigned int st_ctime_nsec;
};
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-16 7:48 ` Christoph Hellwig
@ 2014-05-16 23:06 ` H. Peter Anvin
0 siblings, 0 replies; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-16 23:06 UTC (permalink / raw)
To: Christoph Hellwig, One Thousand Gnomes
Cc: Arnd Bergmann, James Bottomley, Geert Uytterhoeven,
Thomas Gleixner, Ley Foon Tan, Linux-Arch, linux-kernel,
LeyFoon Tan, Chung-Lin Tang
On 05/16/2014 12:48 AM, Christoph Hellwig wrote:
>
> The stat(64) syscall already has stopped time_t for a long time:
>
> struct stat64 {
> ...
> int st_atime; /* Time of last access. */
> unsigned int st_atime_nsec;
> int st_mtime; /* Time of last modification. */
> unsigned int st_mtime_nsec;
> int st_ctime; /* Time of last status change. */
> unsigned int st_ctime_nsec;
> };
>
... except that that is really a struct timespec just written weirdly,
and userspace uses it as a struct timespec.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 20:38 ` Arnd Bergmann
2014-05-15 21:05 ` Joseph S. Myers
@ 2014-05-16 23:11 ` H. Peter Anvin
2014-05-16 23:47 ` Joseph S. Myers
1 sibling, 1 reply; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-16 23:11 UTC (permalink / raw)
To: Arnd Bergmann, Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
>
> For practical purposes in the kernel, we may still want to use 64-bit
> nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> with the native type on 64-bit kernels, thus complicating the syscall
> emulation layer.
>
> I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> problematic.
struct timespec is specified in POSIX as having type "long" for tv_nsec.
This, as Linus pointed out, is totally braindamaged.
x32 does not follow POSIX (Linus pretty much dictated that), and instead
does the __kernel_suseconds_t to match the native kernel type. The
proposal at some point was to try to push a snseconds_t into POSIX.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-16 23:11 ` H. Peter Anvin
@ 2014-05-16 23:47 ` Joseph S. Myers
2014-05-17 0:32 ` H. Peter Anvin
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-16 23:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Arnd Bergmann, Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Sat, 17 May 2014, H. Peter Anvin wrote:
> On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
> >
> > For practical purposes in the kernel, we may still want to use 64-bit
> > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> > with the native type on 64-bit kernels, thus complicating the syscall
> > emulation layer.
> >
> > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > problematic.
>
> struct timespec is specified in POSIX as having type "long" for tv_nsec.
> This, as Linus pointed out, is totally braindamaged.
long is a perfectly reasonable type for this purpose - it's guaranteed to
have enough precision. ISO C11 follows POSIX in the definition of struct
timespec.
> x32 does not follow POSIX (Linus pretty much dictated that), and instead
> does the __kernel_suseconds_t to match the native kernel type. The
> proposal at some point was to try to push a snseconds_t into POSIX.
If the x32 kernel won't be fixed to treat the high part as padding then
glibc will need fixing to copy all struct timespec values passed to the
kernel and clear the padding when copying (really, fixing that bug would
need such copying anyway unless --enable-kernel is used to allow a fixed
kernel to be assumed). In any case, we should not put any more ports into
glibc with that x32 bug; "long" and an explicit padding field is the way
to go (and copying / zeroing if the kernel doesn't treat that padding
field as padding).
Adding snseconds_t to POSIX seems pointless when there is no need for this
field to store values that can't fit in "long". Even if it were added,
good practice would say that implementations should keep using "long"
whenever possible for compatibility with existing applications (just like
the ISO C recommendation "The types used for size_t and ptrdiff_t should
not have an integer conversion rank greater than that of signed long int
unless the implementation supports objects large enough to make this
necessary.").
If you were designing from scratch, no doubt a typedef such as snseconds_t
would be there, but with real-world APIs that have accumulated over time,
deviating from "long" now is a bad idea.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-16 23:47 ` Joseph S. Myers
@ 2014-05-17 0:32 ` H. Peter Anvin
2014-05-18 13:46 ` Joseph S. Myers
0 siblings, 1 reply; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-17 0:32 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Arnd Bergmann, Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On 05/16/2014 04:47 PM, Joseph S. Myers wrote:
>>
>> struct timespec is specified in POSIX as having type "long" for tv_nsec.
>> This, as Linus pointed out, is totally braindamaged.
>
> long is a perfectly reasonable type for this purpose - it's guaranteed to
> have enough precision. ISO C11 follows POSIX in the definition of struct
> timespec.
>
That is not the issue. The issue is that by fixing the type, the POSIX
committee foolishly fixed the ABI unnecessarily. There is nothing wrong
with storing this value in a long, of course, but:
a) there is no reason it needs to be as wide as long, on an LP64 ABI an
int would serve just fine;
b) ABI compatibilility issue, especially since on virtually all ABIs a
96-bit struct timespec would end up padded to 128 bits anyway;
c) gratuitously different from struct timeval.
>> x32 does not follow POSIX (Linus pretty much dictated that), and instead
>> does the __kernel_suseconds_t to match the native kernel type. The
>> proposal at some point was to try to push a snseconds_t into POSIX.
>
> If the x32 kernel won't be fixed to treat the high part as padding then
> glibc will need fixing to copy all struct timespec values passed to the
> kernel and clear the padding when copying (really, fixing that bug would
> need such copying anyway unless --enable-kernel is used to allow a fixed
> kernel to be assumed). In any case, we should not put any more ports into
> glibc with that x32 bug; "long" and an explicit padding field is the way
> to go (and copying / zeroing if the kernel doesn't treat that padding
> field as padding).
>
> Adding snseconds_t to POSIX seems pointless when there is no need for this
> field to store values that can't fit in "long". Even if it were added,
> good practice would say that implementations should keep using "long"
> whenever possible for compatibility with existing applications (just like
> the ISO C recommendation "The types used for size_t and ptrdiff_t should
> not have an integer conversion rank greater than that of signed long int
> unless the implementation supports objects large enough to make this
> necessary.").
That is a very different thing, though.
> If you were designing from scratch, no doubt a typedef such as snseconds_t
> would be there, but with real-world APIs that have accumulated over time,
> deviating from "long" now is a bad idea.
Given that you already have a long long member of the same structure, it
seems unlikely that adding another long long to this is a problem.
Anyway, this was discussed back in 2011:
https://lkml.org/lkml/2011/8/31/244
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-17 0:32 ` H. Peter Anvin
@ 2014-05-18 13:46 ` Joseph S. Myers
2014-05-18 16:10 ` H. Peter Anvin
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-18 13:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Arnd Bergmann, Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Sat, 17 May 2014, H. Peter Anvin wrote:
> > Adding snseconds_t to POSIX seems pointless when there is no need for this
> > field to store values that can't fit in "long". Even if it were added,
> > good practice would say that implementations should keep using "long"
> > whenever possible for compatibility with existing applications (just like
> > the ISO C recommendation "The types used for size_t and ptrdiff_t should
> > not have an integer conversion rank greater than that of signed long int
> > unless the implementation supports objects large enough to make this
> > necessary.").
>
> That is a very different thing, though.
It's advising against breaking compatibility with existing applications
(in that case, C90 applications that assume sizes can be cast to unsigned
long for printing, etc.) unless necessary.
Rich Felker suggests
<https://sourceware.org/bugzilla/show_bug.cgi?id=16438> there are similar
security risks from various types in the x32 ABI being wider than size_t.
That seems entirely plausible, if unconfirmed; I don't think there's been
much effort to look for such issues where applications expect types to be
no wider than size_t when there's no use to them being wider than size_t.
Most of those choices are valid but may be risky to existing software much
as IL32LLP64 can be risky to existing software.
> > If you were designing from scratch, no doubt a typedef such as snseconds_t
> > would be there, but with real-world APIs that have accumulated over time,
> > deviating from "long" now is a bad idea.
>
> Given that you already have a long long member of the same structure, it
> seems unlikely that adding another long long to this is a problem.
>
> Anyway, this was discussed back in 2011:
>
> https://lkml.org/lkml/2011/8/31/244
Just because one buggy port (I consider this quite clearly a bug at the
glibc level, whatever the kernel does, agreeing with Rich Felker in
<https://sourceware.org/bugzilla/show_bug.cgi?id=16437>) managed to get
into glibc does not mean any more should be added. glibc's function is to
provide POSIX (and other) interfaces on top of the underlying kernel,
which includes fixing any mismatch between the kernel and POSIX interfaces
(such as converting from userspace POSIX struct timespec to the form in
which times are passed to the kernel, by copying and zeroing padding, if
necessary). That's just like implementing POSIX threads on top of clone -
or, if future POSIX disallows newlines in filenames (something that's been
discussed for some time but doesn't seem to have seen much action lately)
but the Linux kernel doesn't follow, making such checks on filenames
before passing them to the kernel. Of course, one would hope that the
underlying kernel interfaces are designed to make it straightforward to
implement POSIX on top of them (as well as other things not envisaged by
POSIX).
The userspace ABI for struct timespec with 64-bit time_t and 32-bit long
should use long tv_nsec in any future ports, with appropriate conversion
code in glibc if the kernel interface is different (for ports that started
out with 32-bit time_t, conversion code will be needed anyway to convert
to the 32-bit structure if the new syscalls are unavailable at runtime and
so the old syscalls need to be used, but if the kernel's structure with
64-bit time_t is different from that in userspace then both old and new
kernels need conversion code). Given Rich Felker's bug reports, it seems
reasonable to suppose that musl will wish to do this as well as glibc.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-18 13:46 ` Joseph S. Myers
@ 2014-05-18 16:10 ` H. Peter Anvin
2014-05-18 18:18 ` Joseph S. Myers
0 siblings, 1 reply; 96+ messages in thread
From: H. Peter Anvin @ 2014-05-18 16:10 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Arnd Bergmann, Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On 05/18/2014 06:46 AM, Joseph S. Myers wrote:
>
> It's advising against breaking compatibility with existing applications
> (in that case, C90 applications that assume sizes can be cast to unsigned
> long for printing, etc.) unless necessary.
>
Yes, the values in question will not be a problem for that in this case,
so it doesn't apply.
> Rich Felker suggests
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16438> there are similar
> security risks from various types in the x32 ABI being wider than size_t.
> That seems entirely plausible, if unconfirmed; I don't think there's been
> much effort to look for such issues where applications expect types to be
> no wider than size_t when there's no use to them being wider than size_t.
> Most of those choices are valid but may be risky to existing software much
> as IL32LLP64 can be risky to existing software.
Everything can be risky if done poorly, unfortunately.
> The userspace ABI for struct timespec with 64-bit time_t and 32-bit long
> should use long tv_nsec in any future ports, with appropriate conversion
> code in glibc if the kernel interface is different (for ports that started
> out with 32-bit time_t, conversion code will be needed anyway to convert
> to the 32-bit structure if the new syscalls are unavailable at runtime and
> so the old syscalls need to be used, but if the kernel's structure with
> 64-bit time_t is different from that in userspace then both old and new
> kernels need conversion code). Given Rich Felker's bug reports, it seems
> reasonable to suppose that musl will wish to do this as well as glibc.
This potentially requires the kernel to maintain three separate ABIs if
there is a legacy 32-bit ABI, which is quite frankly idiotic. You seem
to be thinking of POSIX as something handed down by gods, which it
isn't... quite frankly they did something stupid here and should fix
their own mess.
As far as glibc is concerned, this would require glibc to intercept each
ioctl, which is completely infeasible... struct timespec/timeval is
embedded far too deep everywhere.
-hpa
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-18 16:10 ` H. Peter Anvin
@ 2014-05-18 18:18 ` Joseph S. Myers
0 siblings, 0 replies; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-18 18:18 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Arnd Bergmann, Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Sun, 18 May 2014, H. Peter Anvin wrote:
> This potentially requires the kernel to maintain three separate ABIs if
> there is a legacy 32-bit ABI, which is quite frankly idiotic. You seem
Three ABIs seems reasonable enough to me where appropriate.
> to be thinking of POSIX as something handed down by gods, which it
> isn't... quite frankly they did something stupid here and should fix
> their own mess.
In the real world it's useful to support lots of different standard
versions, not just some hypothetical future version (I see no evidence of
anyone thinking there is a POSIX defect actually having raised the issue
with the Austin Group to see if anyone there agrees a change would be
useful). We've only just removed support for _BSD_SOURCE / _SVID_SOURCE
as defined API levels from glibc; I'd guess it will be about 20 years
before removing support for POSIX.1-2008/2013 is appropriate (even if the
next major edition relaxes this requirement).
> As far as glibc is concerned, this would require glibc to intercept each
> ioctl, which is completely infeasible... struct timespec/timeval is
> embedded far too deep everywhere.
Well, maybe the subset of applications passing timespec to ioctls should
carry the cost of converting from the userspace timespec to the kernel
timespec, rather than POSIX applications carrying the cost of unnecessary
incompatibility. (But an enumeration of the relevant ioctls is needed
anyway simply to provide new versions of them all for 64-bit time_t.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-15 21:05 ` Joseph S. Myers
@ 2014-05-19 8:08 ` Arnd Bergmann
2014-05-19 14:46 ` Joseph S. Myers
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-19 8:08 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Thursday 15 May 2014 21:05:03 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Arnd Bergmann wrote:
>
> > > The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to
> > > building libraries that way so a glibc change to the default wouldn't
> > > cause issues for other libraries' ABIs) has gradually been done. The
> > > discussion in March on libc-alpha about changing the default tailed off.
> > > This is something that needs someone to take the lead with a *careful and
> > > detailed analysis of the information from the previous discussion* in
> > > order to present a properly reasoned proposal for a change to the default
> > > - not scattergun patches, not patches with brief or no analysis of the
> > > environment in which glibc is used, not dismissing concerns, but a
> > > properly reasoned argument for why the change should be made, along with
> > > details of how distributions can determine whether ABI issues would arise
> > > from rebuilding a particular library against newer glibc.
> >
> > Ok, I see. I wasn't aware that distributions actually set _FILE_OFFSET_BITS
> > globally for building packages. I guess the effect (from the distro point
> > of view) of that is similar to having a configure option when building glibc
> > as I expected to be the normal way to do it.
>
> I'm not sure they set it globally (modulo the suggestion in that recent
> thread that Gentoo might try changing the default and seeing what breaks)
> - but it at least seems to be set for most libraries for which it affects
> the ABI (whether upstream or by the distributions), based on the sample
> Paul Eggert looked at
> <https://sourceware.org/ml/libc-alpha/2014-03/msg00351.html> (which is an
> important piece of evidence that a change to the default in glibc wouldn't
> be dumping a large problem on distributors regarding the ABIs of many
> widely-used libraries).
I'm mostly worried about the embedded use case, which at least for time_t
would have to build everything the new way as soon as possible. For
desktop and server systems, doing a slow migration to catch the bugs
and never introduce regressions in the field makes a lot of sense,
but when someone today wants to build an embedded system, they already
build everything from source, and it's more important to find all
the bugs now (ideally at compile time) than to have a chance of hitting
a subtle issue 24 years ago on today's build.
For that, it would be nice to even build a glibc that has no backwards
compatibility interfaces for 32-bit time_t at all.
> > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > problematic.
>
> Yes, we have a glibc bug
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
> definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
> "long") being nonconforming, but without the kernel treating upper bits as
> padding, fixing glibc requires wrappers that copy the value and clear the
> upper bits.
Ok. There is also work going on to have an x32-like ABI for ARM64, and
that will likely have to support big-endian as well, so then it's not
just about clearing the padding bits, but also having them in the right
place.
I don't know what happens with powerpc64le, but I assume they will also
at some point want to support 32-bit user space if they don't already.
> > For timeval, I think we don't care about the padding, because we wouldn't
> > use it on new interfaces when the kernel uses nanosecond resolution
> > internally.
>
> Indeed - I haven't checked, but hopefully none of the asm-generic
> interfaces use timeval (and I was suggesting that only the interfaces
> present in asm-generic should be duplicated for 64-bit time_t).
>
> (You also mentioned ioctls. All affected ioctls would need new variants
> unless you have a new variant of the ioctl syscall itself. Logically I
> suppose _TIME_BITS=64 should then map the generic version of an ioctl to
> the 64-bit time_t version so applications don't need to change beyond
> defining _TIME_BITS=64, though I don't know if there's any precedent for
> doing that sort of thing for definitions in kernel headers rather than
> glibc's headers.)
For ioctls, it's not that uncommon to change the definition in the kernel
headers to fix bugs, implying we break compatibility between a user space
tool built against new kernel headers but running on older kernels. That
is already the case for any user space relying on newly introduced ioctls,
so we can e.g. introduce a new ioctl command using a
struct __kernel_timespec64 in one of its structs.
Unfortunately, not every driver installs the header files into the user
visible location, some of them have a copy in their (only) user space
tool. This is still fine if we can catch it and if the driver uses
the correct macro to create the ioctl number, which changes the command
code because of the new argument size. The same would be true if we get
a glibc with 64-bit time_t and old kernel headers that use a 'struct
timespec' or 'time_t' in an ioctl data structure and expect that to
use a 32-bit type. There are probably a small number of those that
also use a malformed command code definition (one that does not take
the structure size into account), and those will cause us problems no
matter what we do.
Another incompatibility is clearly things like include/sound/asound.h
if we decide to change all the structs to use u64 nanosecond timestamps
instead of timespec as we discussed earlier. This means we don't just
have to introduced new command codes but also change all user space
code working with the structs.
The worst case I've found so far is include/linux/if_packet.h, which
uses a memory mapped data structure with 'unsigned int ts_sec'
embedded. It's not possible to translate this at all, and it's also
broken on all 64-bit architectures today. There are already three
versions of that ABI defined though, and I guess there will have to
be another one.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-19 8:08 ` Arnd Bergmann
@ 2014-05-19 14:46 ` Joseph S. Myers
2014-05-19 17:22 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-19 14:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Mon, 19 May 2014, Arnd Bergmann wrote:
> I'm mostly worried about the embedded use case, which at least for time_t
> would have to build everything the new way as soon as possible. For
> desktop and server systems, doing a slow migration to catch the bugs
> and never introduce regressions in the field makes a lot of sense,
> but when someone today wants to build an embedded system, they already
> build everything from source, and it's more important to find all
> the bugs now (ideally at compile time) than to have a chance of hitting
> a subtle issue 24 years ago on today's build.
>
> For that, it would be nice to even build a glibc that has no backwards
> compatibility interfaces for 32-bit time_t at all.
Building glibc without compatibility interfaces is --enable-oldest-abi (to
disable ABIs obsoleted before a given point, so that if the 32-bit time_t
interfaces are obsoleted and no longer available for new builds then it
would disable them) - but that's been bitrotten for years
<https://sourceware.org/bugzilla/show_bug.cgi?id=6652> and there is
consensus to remove it if anyone sends a patch. (Similarly,
--disable-versioning support was removed. The sort of really tiny
embedded systems for which that sort of thing is relevant as space
reduction no longer seem so relevant to glibc; there has been no interest
in merging option group support from EGLIBC to glibc now EGLIBC
development has been discontinued.)
Now, when the motivation is not space reduction but ensuring nothing is
there that will break in 2038 (unless it's doing dubious things like
storing a time_t value in an int or long in the application - something a
reasonably stupid static analysis should be able to detect), you could
always identify the (symbol, version) pairs for a given architecture that
use 32-bit time_t and develop a tool that checks for binaries using
problem symbols. (Of course, that won't help with ioctls.) Or put a
small patch in the headers to force _TIME_BITS=64 and not allow an
override with _TIME_BITS=32. And if the kernel had a config option to
disable all the old interfaces, that would make problem binaries break now
rather than in 2038.
> > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > problematic.
> >
> > Yes, we have a glibc bug
> > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
> > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
> > "long") being nonconforming, but without the kernel treating upper bits as
> > padding, fixing glibc requires wrappers that copy the value and clear the
> > upper bits.
>
> Ok. There is also work going on to have an x32-like ABI for ARM64, and
> that will likely have to support big-endian as well, so then it's not
> just about clearing the padding bits, but also having them in the right
> place.
Yes, I see no problem with putting the padding bits in the right place so
that when the kernel is passing struct timespec values *to* userspace, it
can just fill in the native 64-bit structure and have it automatically be
correct when interpreted as a 32-bit structure with padding (which the
kernel will have zeroed implicitly) on tv_nsec.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-19 14:46 ` Joseph S. Myers
@ 2014-05-19 17:22 ` Arnd Bergmann
2014-05-19 18:12 ` Joseph S. Myers
0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-19 17:22 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Monday 19 May 2014 14:46:59 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> Now, when the motivation is not space reduction but ensuring nothing is
> there that will break in 2038 (unless it's doing dubious things like
> storing a time_t value in an int or long in the application - something a
> reasonably stupid static analysis should be able to detect), you could
> always identify the (symbol, version) pairs for a given architecture that
> use 32-bit time_t and develop a tool that checks for binaries using
> problem symbols. (Of course, that won't help with ioctls.) Or put a
> small patch in the headers to force _TIME_BITS=64 and not allow an
> override with _TIME_BITS=32. And if the kernel had a config option to
> disable all the old interfaces, that would make problem binaries break now
> rather than in 2038.
I had already thought of the kernel option, that's probably one thing
we will do here, but it won't help if glibc then emulates the interfaces
we remove ;-)
A related question would be how you plan to support future CPU architectures
that never had the 32-bit time_t in the kernel ABI. Would you also want
to provide both 32 and 64 bit time_t to user space on those?
Then again I'm not sure how relevant glibc is to the deeply embedded
distros that would want to run without the backwards compatibility.
I suspect that uClibc, musl and bionic would just offer a compile time
switch without any emulation.
> > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > > problematic.
> > >
> > > Yes, we have a glibc bug
> > > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
> > > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
> > > "long") being nonconforming, but without the kernel treating upper bits as
> > > padding, fixing glibc requires wrappers that copy the value and clear the
> > > upper bits.
> >
> > Ok. There is also work going on to have an x32-like ABI for ARM64, and
> > that will likely have to support big-endian as well, so then it's not
> > just about clearing the padding bits, but also having them in the right
> > place.
>
> Yes, I see no problem with putting the padding bits in the right place so
> that when the kernel is passing struct timespec values *to* userspace, it
> can just fill in the native 64-bit structure and have it automatically be
> correct when interpreted as a 32-bit structure with padding (which the
> kernel will have zeroed implicitly) on tv_nsec.
Ok.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-19 17:22 ` Arnd Bergmann
@ 2014-05-19 18:12 ` Joseph S. Myers
2014-05-19 18:20 ` Arnd Bergmann
0 siblings, 1 reply; 96+ messages in thread
From: Joseph S. Myers @ 2014-05-19 18:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Mon, 19 May 2014, Arnd Bergmann wrote:
> A related question would be how you plan to support future CPU architectures
> that never had the 32-bit time_t in the kernel ABI. Would you also want
> to provide both 32 and 64 bit time_t to user space on those?
I'd expect those just to have 64-bit time_t in userspace (like x32) -
choosing a different type for time_t from the start is a lot simpler than
setting up a second set of interfaces with associated symbol versioning
for an existing architecture. This whole discussion started with the
question of whether Nios II should be such an architecture....
(Other variants may arise as well, e.g. architectures with existing kernel
support that only get glibc support later.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
2014-05-19 18:12 ` Joseph S. Myers
@ 2014-05-19 18:20 ` Arnd Bergmann
0 siblings, 0 replies; 96+ messages in thread
From: Arnd Bergmann @ 2014-05-19 18:20 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Chung-Lin Tang, John Stultz, Geert Uytterhoeven,
Christoph Hellwig, Thomas Gleixner, Ley Foon Tan, Linux-Arch,
linux-kernel, LeyFoon Tan
On Monday 19 May 2014 18:12:18 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> > A related question would be how you plan to support future CPU architectures
> > that never had the 32-bit time_t in the kernel ABI. Would you also want
> > to provide both 32 and 64 bit time_t to user space on those?
>
> I'd expect those just to have 64-bit time_t in userspace (like x32) -
> choosing a different type for time_t from the start is a lot simpler than
> setting up a second set of interfaces with associated symbol versioning
> for an existing architecture. This whole discussion started with the
> question of whether Nios II should be such an architecture....
Ok
> (Other variants may arise as well, e.g. architectures with existing kernel
> support that only get glibc support later.)
Good point.
Arnd
^ permalink raw reply [flat|nested] 96+ messages in thread
end of thread, other threads:[~2014-05-19 18:20 UTC | newest]
Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-13 8:57 [PATCH 00/25] Change time_t and clock_t to 64 bit Ley Foon Tan
2014-05-13 9:02 ` [PATCH 01/25] asm-generic: " Ley Foon Tan
2014-05-13 9:15 ` James Hogan
2014-05-13 9:30 ` Thomas Gleixner
2014-05-13 9:32 ` Ley Foon Tan
2014-05-13 9:50 ` James Hogan
2014-05-13 10:17 ` Ley Foon Tan
2014-05-13 10:21 ` Arnd Bergmann
2014-05-13 12:07 ` Thomas Gleixner
2014-05-13 13:11 ` Geert Uytterhoeven
2014-05-13 13:38 ` Arnd Bergmann
2014-05-13 14:37 ` Thomas Gleixner
2014-05-13 10:22 ` James Hogan
2014-05-14 3:47 ` H. Peter Anvin
2014-05-14 10:44 ` Geert Uytterhoeven
2014-05-13 9:02 ` [PATCH 02/25] arc: Add 32 bit time_t and clock_t Ley Foon Tan
2014-05-13 9:02 ` [PATCH 03/25] arm: " Ley Foon Tan
2014-05-13 9:02 ` [PATCH 04/25] avr32: " Ley Foon Tan
2014-05-13 20:19 ` Hans-Christian Egtvedt
2014-05-14 1:54 ` Ley Foon Tan
2014-05-14 7:44 ` Hans-Christian Egtvedt
2014-05-14 21:39 ` H. Peter Anvin
2014-05-13 9:02 ` [PATCH 05/25] blackfin: " Ley Foon Tan
2014-05-13 9:03 ` [PATCH 06/25] c6x: " Ley Foon Tan
2014-05-13 9:03 ` [PATCH 08/25] frv: " Ley Foon Tan
2014-05-13 9:03 ` [PATCH 09/25] hexagon: " Ley Foon Tan
2014-05-13 9:03 ` [PATCH 10/25] m32r: " Ley Foon Tan
2014-05-13 9:03 ` [PATCH 11/25] m68k: " Ley Foon Tan
2014-05-13 9:04 ` [PATCH 12/25] metag: " Ley Foon Tan
2014-05-13 9:22 ` James Hogan
2014-05-13 9:28 ` Ley Foon Tan
2014-05-13 9:05 ` [PATCH 13/25] microblaze: " Ley Foon Tan
2014-05-13 9:05 ` [PATCH 14/25] mips: " Ley Foon Tan
2014-05-13 9:05 ` [PATCH 15/25] mn10300: " Ley Foon Tan
2014-05-13 9:05 ` [PATCH 16/25] openrisc: " Ley Foon Tan
2014-05-13 9:30 ` Jonas Bonn
2014-05-13 9:41 ` Ley Foon Tan
2014-05-13 9:06 ` [PATCH 17/25] parisc: " Ley Foon Tan
2014-05-13 20:17 ` Helge Deller
2014-05-14 1:57 ` Ley Foon Tan
2014-05-15 0:34 ` H. Peter Anvin
2014-05-13 9:06 ` [PATCH 19/25] s390: " Ley Foon Tan
2014-05-13 9:06 ` [PATCH 20/25] score: " Ley Foon Tan
2014-05-13 9:06 ` [PATCH 21/25] sh: " Ley Foon Tan
2014-05-13 9:06 ` [PATCH 22/25] sparc: " Ley Foon Tan
2014-05-13 9:06 ` [PATCH 23/25] unicore32: " Ley Foon Tan
2014-05-13 9:06 ` [PATCH 25/25] xtense: " Ley Foon Tan
2014-05-13 9:10 ` [PATCH 07/25] cris: " Ley Foon Tan
2014-05-13 9:10 ` [PATCH 00/25] Change time_t and clock_t to 64 bit Geert Uytterhoeven
2014-05-13 9:23 ` Ley Foon Tan
2014-05-13 15:24 ` Christoph Hellwig
2014-05-13 15:33 ` Thomas Gleixner
2014-05-13 17:46 ` Christoph Hellwig
2014-05-13 18:10 ` Arnd Bergmann
2014-05-13 18:24 ` Geert Uytterhoeven
2014-05-13 19:32 ` Arnd Bergmann
2014-05-13 20:35 ` Geert Uytterhoeven
2014-05-14 11:00 ` Arnd Bergmann
2014-05-14 12:21 ` Thomas Gleixner
2014-05-14 14:01 ` Arnd Bergmann
2014-05-14 14:46 ` Thomas Gleixner
2014-05-14 15:48 ` Arnd Bergmann
2014-05-15 15:47 ` James Bottomley
2014-05-15 16:36 ` Arnd Bergmann
2014-05-15 21:07 ` One Thousand Gnomes
2014-05-16 7:48 ` Christoph Hellwig
2014-05-16 23:06 ` H. Peter Anvin
2014-05-14 21:33 ` John Stultz
2014-05-15 0:14 ` H. Peter Anvin
2014-05-15 3:32 ` Nicolas Pitre
2014-05-15 11:08 ` Arnd Bergmann
2014-05-15 11:18 ` Christoph Hellwig
2014-05-15 17:11 ` Chung-Lin Tang
2014-05-15 17:12 ` Chung-Lin Tang
2014-05-15 18:01 ` Joseph S. Myers
2014-05-15 19:18 ` Arnd Bergmann
2014-05-15 20:10 ` Joseph S. Myers
2014-05-15 20:38 ` Arnd Bergmann
2014-05-15 21:05 ` Joseph S. Myers
2014-05-19 8:08 ` Arnd Bergmann
2014-05-19 14:46 ` Joseph S. Myers
2014-05-19 17:22 ` Arnd Bergmann
2014-05-19 18:12 ` Joseph S. Myers
2014-05-19 18:20 ` Arnd Bergmann
2014-05-16 23:11 ` H. Peter Anvin
2014-05-16 23:47 ` Joseph S. Myers
2014-05-17 0:32 ` H. Peter Anvin
2014-05-18 13:46 ` Joseph S. Myers
2014-05-18 16:10 ` H. Peter Anvin
2014-05-18 18:18 ` Joseph S. Myers
2014-05-14 10:13 ` Ley Foon Tan
2014-05-14 10:33 ` Arnd Bergmann
2014-05-14 21:04 ` H. Peter Anvin
2014-05-13 18:15 ` Geert Uytterhoeven
2014-05-13 19:14 ` Thomas Gleixner
2014-05-14 3:36 ` [PATCH 24/25] x86: Add 32 bit time_t and clock_t Ley Foon Tan
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).