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

[Daniel Palmer]

Hi Thomas,

On Thu, 14 May 2026 at 23:20, Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote:
> > Do you think there is a way to do statfs() properly in the future? I
> > actually started using it in a mini (~64KB) userland I am building so
> > I can get Linux to boot in 3.5MB of RAM.
>
> What exactly do you need out of statfs?

Total and used space on mounted filesystems. There doesn't seem to be
any other way to get it.

> > I considered just copying the 64bit version of the statfs struct into
> > nolibc so we don't need to use the UAPI header but it seemed like MIPS
> > has a bunch of different versions of it so it wouldn't work on MIPS.
>
> I think we can do something like this:
>
> #define statfs __nolibc_kernel_statfs
> #define statfs64 __nolibc_kernel_statfs64
> #include <asm/statfs.h>
> #undef statfs
> #undef statfs64
>
> #define __nolibc_cloned_member(_orig_struct, _name) \
>         __nolibc_typeof_member(_orig_struct, _name) _name __nolibc_alignof_member(_orig_struct, _name)
>
> struct statfs {
>         __nolibc_cloned_member(struct __nolibc_kernel_statfs64, f_type);
>         __nolibc_cloned_member(struct __nolibc_kernel_statfs64, f_bsize);
>         ...
> };
>
> And then in nolibc-test add a bunch of assertions which makes sure that
> the structures are actually compatible. (Fields have the same offsets
> and the structures are the same size). This way we can reuse the
> structure definitions from the UAPI definitions but avoid the macro
> pollution.
>
> We do something similar for the time types, too.

Interesting. I'll have a go at this but separately from the fallocate() part.

Cheers,

Daniel