Displaying 6 results from an estimated 6 matches for "__kernel_time64_t".
2015 May 18
5
kernel/libc uapi changes for y2038
In the patch series I posted recently [1], I introduce new system calls to deal
with modified data structures, but left the question open on how these should
be best accessed from libc. The patches introduce a new __kernel_time64_t type
and based on that five new data structured: struct __kernel_timespec,
struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage,
and struct __kernel_timex. This works fine for the case when all libc
implementations provide their own definitions to user space, but not for
the sim...
2023 Jan 14
1
[klibc:time64] time: Use 64-bit time types on all architectures
...39ee4c313e368dfe967
Author: Ben Hutchings <ben at decadent.org.uk>
AuthorDate: Sat, 14 Jan 2023 00:17:45 +0100
Committer: Ben Hutchings <ben at decadent.org.uk>
CommitDate: Sat, 14 Jan 2023 18:10:12 +0100
[klibc] time: Use 64-bit time types on all architectures
- Define time_t as __kernel_time64_t
- In <sys/time.h>, replace <linux/time.h> with suitable
definitions:
- Define struct timespec and itimerspec to match the kernel's 64-bit
structures
- Define struct timeval using __kernel_time64_t (although there
are no new system calls using struct timeval)
- Keep t...
2015 May 27
0
kernel/libc uapi changes for y2038
On 05/18/2015 02:53 AM, Arnd Bergmann wrote:
> In the patch series I posted recently [1], I introduce new system calls to deal
> with modified data structures, but left the question open on how these should
> be best accessed from libc. The patches introduce a new __kernel_time64_t type
> and based on that five new data structured: struct __kernel_timespec,
> struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage,
> and struct __kernel_timex. This works fine for the case when all libc
> implementations provide their own definitions to user space,...
2023 Jan 14
1
[klibc:time64] time: Use 64-bit time types on all architectures
On Sat, Jan 14, 2023, at 23:03, klibc-bot for Ben Hutchings wrote:
>
> #include <klibc/extern.h>
> +#include <klibc/endian.h>
> #include <stddef.h>
> #include <sys/types.h>
> -#include <linux/time.h>
> +
> +struct timespec {
> + __kernel_time64_t tv_sec;
> +#if __BYTE_ORDER == __BIG_ENDIAN && __BITS_PER_LONG == 32
> + long __tv_pad;
> +#endif
> + long tv_nsec;
> +#if __BYTE_ORDER == __LITTLE_ENDIAN && __BITS_PER_LONG == 32
> + long __tv_pad;
> +#endif
> +};
The problem with this definition is a...
2015 May 18
0
kernel/libc uapi changes for y2038
Arnd Bergmann dixit:
>In the patch series I posted recently [1], I introduce new system calls to deal
>with modified data structures, but left the question open on how these should
>be best accessed from libc. The patches introduce a new __kernel_time64_t type
Can we please have ioctls fixed for mixed 32/64-bit systems
such as MIPS (o32/n32/n64) and x86 (i386/x32/amd64) first,
before even more such chance for breakage is introduced?
I still need to use an amd64 chroot on my x32 system to do
things such as set up iptables, because those ioctls brea...
2015 May 18
2
[Y2038] kernel/libc uapi changes for y2038
...:48 Thorsten Glaser wrote:
> Arnd Bergmann dixit:
>
> >In the patch series I posted recently [1], I introduce new system calls to deal
> >with modified data structures, but left the question open on how these should
> >be best accessed from libc. The patches introduce a new __kernel_time64_t type
>
> Can we please have ioctls fixed for mixed 32/64-bit systems
> such as MIPS (o32/n32/n64) and x86 (i386/x32/amd64) first,
> before even more such chance for breakage is introduced?
It's hard because we don't even know what ioctls are affected at this point,
and I was h...