From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Daniel Palmer <daniel@thingy.jp>
Cc: w@1wt.eu, david.laight.linux@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] tools/nolibc: Add statfs()
Date: Thu, 14 May 2026 16:20:07 +0200 [thread overview]
Message-ID: <96c1a48a-657d-4916-a5ec-155485aea4ea@t-8ch.de> (raw)
In-Reply-To: <CAFr9PX=QknPT8rqPDGt=dV851JBRkMuDHLLuqJVXLO1tLzy+dQ@mail.gmail.com>
On 2026-05-14 22:05:37+0900, Daniel Palmer wrote:
> Hi Thomas,
>
> On Thu, 14 May 2026 at 21:40, Thomas Weißschuh <linux@weissschuh.net> wrote:
> >
> > On 2026-05-14 21:28:19+0900, Daniel Palmer wrote:
> > > On Thu, 14 May 2026 at 20:42, Thomas Weißschuh <linux@weissschuh.net> 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?
(...)
> 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?
> 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.
Thomas
next prev parent reply other threads:[~2026-05-14 14:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 9:03 [PATCH v4 0/3] nolibc: Add fallocate() Daniel Palmer
2026-05-07 9:03 ` [PATCH v4 1/3] tools/nolibc: fcntl: " Daniel Palmer
2026-05-07 9:03 ` [PATCH v4 2/3] tools/nolibc: Add statfs() Daniel Palmer
2026-05-14 11:42 ` Thomas Weißschuh
2026-05-14 12:28 ` Daniel Palmer
2026-05-14 12:40 ` Thomas Weißschuh
2026-05-14 13:05 ` Daniel Palmer
2026-05-14 14:20 ` Thomas Weißschuh [this message]
2026-05-14 14:41 ` Daniel Palmer
2026-05-14 13:29 ` Willy Tarreau
2026-05-07 9:03 ` [PATCH v4 3/3] selftests/nolibc: Add a very basic test for fallocate() Daniel Palmer
2026-05-11 6:29 ` [PATCH v4 0/3] nolibc: Add fallocate() Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96c1a48a-657d-4916-a5ec-155485aea4ea@t-8ch.de \
--to=linux@weissschuh.net \
--cc=daniel@thingy.jp \
--cc=david.laight.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox