Re: [PATCH v4 2/3] tools/accounting: factor out shared format_timespec() implementation

[Thomas Weißschuh]

+Cc Arnd

On Sat, Aug 22, 2026 at 05:51:22PM +0800, wang.yaxin@xxxxxxxxxx wrote:
> >> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> >> +#ifndef _TOOLS_UAPI_LINUX_TIME_TYPES_H
> >> +#define _TOOLS_UAPI_LINUX_TIME_TYPES_H
> >> +
> >> +#include <linux/types.h>
> >> +#include <asm/posix_types.h>
> >
> >So the tools/include/ header are supposed to be platform independent and standalone.
> >But this relies on an asm/ header which itself is not part of tools/include/.
> >The addition of this header did not remove the dependency on system UAPI headers.
> >
> >So why is this new header copy needed in its current form?
> 
> Thank you for identifying this issue. We agree that `#include <asm/posix_types.h>`
> creates an undesirable dependency on system headers.
> 
> The problem: System headers (`/usr/include/asm-generic/posix_types.h`) are outdated
> and lack `__kernel_old_time_t` (a y2038 fix added in the kernel). Simply removing
> the include would cause compilation failures.

Thanks for the explanation.

> Our fix (two steps):
> 
> 1. Change `time_types.h` to use `#include <asm-generic/posix_types.h>`
>    - This is architecture-independent: `asm-generic/posix_types.h` directly defines
>      all POSIX types (`__kernel_long_t`, `__kernel_time64_t`, `__kernel_old_time_t`)
>      without architecture-specific dispatching

While it defines all posix types, these are not necessarily correct for all architectures.
If they were, we wouldn't need the whole asm-generic machinery in the first place.

>    - This follows the same pattern as `types.h` which uses `<asm-generic/int-ll64.h>`

int-ll64.h is special. It can't be used as an example here.

> 2. Copy `include/uapi/asm-generic/posix_types.h` to `tools/include/uapi/asm-generic/`
>    - This restores the self-containment of tools/include/uapi/
>    - The copied file provides up-to-date type definitions (including y2038 fixes)
>    - No longer relies on outdated system headers
> 
> This addresses your concern by making `time_types.h` truly self-contained and
> architecture-independent within tools/include/.

Please see my new concerns above.

Given that __kernel_old_time_t was introduced in v5.5 I am not sure if we still
want to support that old UAPI headers.
If we do, I think the better solution would be to add "typedef __kernel_long_t
__kernel_old_time_t;" to the tools/ header which needs __kernel_old_time_t.


Thomas