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

[Thomas Weißschuh]

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().


Thomas