On Mon, Feb 18, 2019 at 11:40 PM Joseph Myers joseph@codesourcery.com wrote:
On Mon, 18 Feb 2019, Arnd Bergmann wrote:
We don't yet have an upstream glibc port for csky, so there is no user
We do. It's in 2.29.
... On Tue, Feb 19, 2019 at 3:18 AM Guo Ren guoren@kernel.org wrote:
Mao Han has merged csky port into glibc 2.29, so we should keep the __ARCH_WANT_TIME32_SYSCALLS.
My mistake. I've dropped patch 7/8 from this series now.
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig index 6959e0b1e956..398113c845f5 100644 --- a/arch/csky/Kconfig +++ b/arch/csky/Kconfig @@ -1,6 +1,5 @@ config CSKY def_bool y
select ARCH_32BIT_OFF_T select ARCH_HAS_SYNC_DMA_FOR_CPU select ARCH_HAS_SYNC_DMA_FOR_DEVICE select ARCH_USE_BUILTIN_BSWAPdiff --git a/arch/csky/include/uapi/asm/unistd.h b/arch/csky/include/uapi/asm/unistd.h index ec60e49cea66..224c9a9ab45b 100644 --- a/arch/csky/include/uapi/asm/unistd.h +++ b/arch/csky/include/uapi/asm/unistd.h @@ -2,8 +2,6 @@ // Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
#define __ARCH_WANT_SYS_CLONE -#define __ARCH_WANT_SET_GET_RLIMIT
Seems it's not related to y2038 issue. Is __ARCH_WANT_SET_GET_RLIMIT no use ?
In new architectures, we do not need to set CONFIG_ARCH_32BIT_OFF_T or __ARCH_WANT_SET_GET_RLIMIT, since we can assume that user space always uses a 64-bit off_t and a 'struct rlimit' matching the kernel's rlimit64, with the prlimit64() system call replacing both getrlimit and setrlimit on the kernel/user ABI side.
I don't know if glibc still uses the 32-bit off_t behavior or the old getrlimit/setrlimit, but if we're not also changing the time32 interfaces, the safest option seems to be to leave all three in place.
Arnd