Displaying 3 results from an estimated 3 matches for "__kernel_time_bits".
2015 May 18
5
kernel/libc uapi changes for y2038
...elopers prefer, so here is
an alternative approach, as a patch on top of the previous series:
Now, we rename the original structures to struct __old_kernel_*, and use a
macro to define either the __old_kernel_* or the __kernel_* structure name
to the name we actually want in user space, based on a __KERNEL_TIME_BITS
macro that can be set to either 32 or 64 for 32-bit architectures by
the libc. Depending on that macro, the compiler will either see one
of these combinations (for each of the five structures):
a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32:
struct timespec based on...
2015 May 27
0
kernel/libc uapi changes for y2038
...s
> an alternative approach, as a patch on top of the previous series:
>
> Now, we rename the original structures to struct __old_kernel_*, and use a
> macro to define either the __old_kernel_* or the __kernel_* structure name
> to the name we actually want in user space, based on a __KERNEL_TIME_BITS
> macro that can be set to either 32 or 64 for 32-bit architectures by
> the libc. Depending on that macro, the compiler will either see one
> of these combinations (for each of the five structures):
>
> a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32:
>
> str...
2015 May 18
2
[Y2038] kernel/libc uapi changes for y2038
...have a properly defined (using _IOW()/_IOR()/_IORW()) command number:
these are easy enough to find and fix.
b) ioctls that have a data structure as before but define their ioctl
commands differently (e.g. using a literal number). I don't think
we can fix them before we introduce the __KERNEL_TIME_BITS macro
from my patch, because user space needs to see a different command
number here, and we have a lot of these.
c) ioctls that are defined ad-hoc, without any uapi header containing
the structure, but using a proper _IOW()/_IOR()/_IORW() macro.
These are much harder to find than a),...