A custom 'struct timespec' will be necessary for 64-bit time types on
32-bit architectures. <linux/time.h> will define other time-related
types in terms of the custom definition.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 tools/include/nolibc/arch-s390.h | 3 +++
 tools/include/nolibc/types.h     | 9 ++++++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
index 6237211385c0..1e87ac42ab9c 100644
--- a/tools/include/nolibc/arch-s390.h
+++ b/tools/include/nolibc/arch-s390.h
@@ -5,6 +5,9 @@
 
 #ifndef _NOLIBC_ARCH_S390_H
 #define _NOLIBC_ARCH_S390_H
+
+#include "types.h"
+
 #include <linux/signal.h>
 #include <linux/unistd.h>
 
diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
index 16c6e9ec9451..4f5a25567e5c 100644
--- a/tools/include/nolibc/types.h
+++ b/tools/include/nolibc/types.h
@@ -13,9 +13,16 @@
 #include "std.h"
 #include <linux/mman.h>
 #include <linux/stat.h>
-#include <linux/time.h>
 #include <linux/wait.h>
 
+struct timespec {
+	time_t	tv_sec;
+	long	tv_nsec;
+};
+#define _STRUCT_TIMESPEC
+
+#include <linux/time.h>
+
 
 /* Only the generic macros and types may be defined here. The arch-specific
  * ones such as the O_RDONLY and related macros used by fcntl() and open()

-- 
2.51.1.dirty

On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> 
> +struct timespec {
> +	time_t	tv_sec;
> +	long	tv_nsec;
> +};
> +#define _STRUCT_TIMESPEC
> +
> +#include <linux/time.h>

Unfortunately this is not the definition we want on big-endian
systems because it puts the tv_nsec field in the wrong place.

You can either uses the simple (non-POSIX) __kernel_timespec
definition in nolibc with a 64-bit tv_nsec, or copy the more
complicated definition with explicit padding that is used
in musl and glibc.

      Arnd

On Thu, Oct 30, 2025 at 03:46:21PM +0100, Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> > 
> > +struct timespec {
> > +	time_t	tv_sec;
> > +	long	tv_nsec;
> > +};
> > +#define _STRUCT_TIMESPEC
> > +
> > +#include <linux/time.h>
> 
> Unfortunately this is not the definition we want on big-endian
> systems because it puts the tv_nsec field in the wrong place.

Indeed!

> You can either uses the simple (non-POSIX) __kernel_timespec
> definition in nolibc with a 64-bit tv_nsec, or copy the more
> complicated definition with explicit padding that is used
> in musl and glibc.

I think that switching this patch and the next one (10/12) would
just do the trick since both fields will become __kernel_time64_t.
Or maybe the two should be squashed into a single one.

Willy

On 2025-11-02 09:36:22+0100, Willy Tarreau wrote:
> On Thu, Oct 30, 2025 at 03:46:21PM +0100, Arnd Bergmann wrote:
> > On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> > > 
> > > +struct timespec {
> > > +	time_t	tv_sec;
> > > +	long	tv_nsec;
> > > +};
> > > +#define _STRUCT_TIMESPEC
> > > +
> > > +#include <linux/time.h>
> > 
> > Unfortunately this is not the definition we want on big-endian
> > systems because it puts the tv_nsec field in the wrong place.
> 
> Indeed!
> 
> > You can either uses the simple (non-POSIX) __kernel_timespec
> > definition in nolibc with a 64-bit tv_nsec, or copy the more
> > complicated definition with explicit padding that is used
> > in musl and glibc.
> 
> I think that switching this patch and the next one (10/12) would
> just do the trick since both fields will become __kernel_time64_t.
> Or maybe the two should be squashed into a single one.

Maybe I can make it clearer that this patch does not change anything.
This custom definition of 'struct timespec' is the same as the one we
got from linux/time.h before. This is just a preparation for the next
commit. Merging would also work, but it will be a bit messy to look at.


Thomas

On Sun, Nov 02, 2025 at 10:41:39AM +0100, Thomas Weißschuh wrote:
> On 2025-11-02 09:36:22+0100, Willy Tarreau wrote:
> > On Thu, Oct 30, 2025 at 03:46:21PM +0100, Arnd Bergmann wrote:
> > > On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> > > > 
> > > > +struct timespec {
> > > > +	time_t	tv_sec;
> > > > +	long	tv_nsec;
> > > > +};
> > > > +#define _STRUCT_TIMESPEC
> > > > +
> > > > +#include <linux/time.h>
> > > 
> > > Unfortunately this is not the definition we want on big-endian
> > > systems because it puts the tv_nsec field in the wrong place.
> > 
> > Indeed!
> > 
> > > You can either uses the simple (non-POSIX) __kernel_timespec
> > > definition in nolibc with a 64-bit tv_nsec, or copy the more
> > > complicated definition with explicit padding that is used
> > > in musl and glibc.
> > 
> > I think that switching this patch and the next one (10/12) would
> > just do the trick since both fields will become __kernel_time64_t.
> > Or maybe the two should be squashed into a single one.
> 
> Maybe I can make it clearer that this patch does not change anything.
> This custom definition of 'struct timespec' is the same as the one we
> got from linux/time.h before. This is just a preparation for the next
> commit. Merging would also work, but it will be a bit messy to look at.

Yes a slightly improved description in the patch wouldn't hurt. Since
we were two to get caught, it will definitely happen in the future when
people read commits.

Thanks!
Willy

On Sun, Nov 02, 2025 at 09:36:22AM +0100, Willy Tarreau wrote:
> On Thu, Oct 30, 2025 at 03:46:21PM +0100, Arnd Bergmann wrote:
> > On Wed, Oct 29, 2025, at 17:02, Thomas Weißschuh wrote:
> > > 
> > > +struct timespec {
> > > +	time_t	tv_sec;
> > > +	long	tv_nsec;
> > > +};
> > > +#define _STRUCT_TIMESPEC
> > > +
> > > +#include <linux/time.h>
> > 
> > Unfortunately this is not the definition we want on big-endian
> > systems because it puts the tv_nsec field in the wrong place.
> 
> Indeed!
> 
> > You can either uses the simple (non-POSIX) __kernel_timespec
> > definition in nolibc with a 64-bit tv_nsec, or copy the more
> > complicated definition with explicit padding that is used
> > in musl and glibc.
> 
> I think that switching this patch and the next one (10/12) would
> just do the trick since both fields will become __kernel_time64_t.
> Or maybe the two should be squashed into a single one.

OK like Arnd, I just saw with the last commit that this one will not
harm. That's good.

Willy