Re: [PATCH v4 2/3] tools/nolibc: Add statfs()
From: Daniel Palmer
Date: Thu May 14 2026 - 09:05:58 EST
Hi Thomas,
On Thu, 14 May 2026 at 21:40, Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote:
>
> On 2026-05-14 21:28:19+0900, Daniel Palmer wrote:
> > On Thu, 14 May 2026 at 20:42, Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote:
> > > > +/* 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.
> > > 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?
> >
> > I thought maybe we could look at /proc/mounts but it seems like if
> > tmpfs is actually ramfs (CONFIG_SHMEM=n) it still shows tmpfs as the
> > filesystem type.
> > So we'd be back to square one. Maybe look for tmpfs in /proc/mounts
> > then try something that ramfs doesn't support like creating a tmp file
> > and fallocate() on it to see if it's ramfs?
>
> Why not check for EOPNOTSUPP from fallocate() and skip the test in that
> case? This would also allow the test to run on a regular filesystem on
> /tmp which does support fallocate().
Yeah that makes sense. I will drop this patch and adjust the test so
we check for fallocate().
I think I'll add a check for the size of the filesystem /tmp is on so
we don't attempt to create a massive file. I was assuming because /tmp
should be tmpfs attempting to allocate a file in RAM bigger than most
CPUs can physically address would be ok. If /tmp could be a real disk
I think it's safer to check. :)
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.
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.
Cheers,
Daniel