Re: [PATCH v4 2/3] tools/nolibc: Add statfs()

[Willy Tarreau]

On Thu, May 14, 2026 at 01:42:42PM +0200, Thomas Weißschuh wrote:
> On 2026-05-07 18:03:52+0900, Daniel Palmer wrote:
> > Add statfs().

BTW Daniel, given the number of hacks the patch relies on, it's
important to explain the challenges and choices in the commit
message, as this patch is not adding just a wrapper around a
syscall number.

> > --- /dev/null
> > +++ b/tools/include/nolibc/sys/statfs.h
> > @@ -0,0 +1,50 @@
> > +/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
> > +/*
> > + * statfs for NOLIBC
> > + * Copyright (C) 2026 Daniel Palmer <daniel@xxxxxxxxx>
> > + */
> > +
> > +/* make sure to include all global symbols */
> > +#include "../nolibc.h"
> > +
> > +#ifndef _NOLIBC_SYS_STATFS_H
> > +#define _NOLIBC_SYS_STATFS_H
> > +
> > +#include "../sys.h"
> > +
> > +/* Some preprocessor hackery to get struct statfs to
> > + * always be the 64bit one.
> > + */
> > +#define statfs __nolibc_kernel_statfs
> > +#define statfs64 __nolibc_kernel_statfs64
> > +#include <asm/statfs.h>
> > +#undef statfs
> > +#undef statfs64
> > +
> > +#ifdef __NR_statfs64
> > +#define statfs __nolibc_kernel_statfs64
> > +#else
> > +#define statfs __nolibc_kernel_statfs
> > +#endif
> 
> This #define can wreak havoc in user code.

Indeed.

> While it would be nice to have statfs() in nolibc,
> I don't see a proper way to work with the current UAPI header.
> Can we do without statfs() for now?

Well, in its origins, nolibc used to redefine all the structures it
needed. It was not great of course and I'm very happy that this period
is gone. But here we're facing a perfect case of discrepancy between
an exposed kernel structure and the one supposed to be presented to
the application.

Here it's not as if the structures were complex, maybe we should just
define the application-visible statfs ourselves and be done with it.
It's what any application will have to do to use this syscall as long
as we don't provide it ourselves anyway, except that we have a better
view of the differences between architectures and there's less risks
of mistakes if centralized into nolibc.

Willy