From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Daniel Palmer <daniel@thingy.jp>,
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 15:29:01 +0200 [thread overview]
Message-ID: <agXOHVbclfZqbmTL@1wt.eu> (raw)
In-Reply-To: <7afa6d33-1673-4766-b939-301597e675ed@t-8ch.de>
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@thingy.jp>
> > + */
> > +
> > +/* 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
next prev parent reply other threads:[~2026-05-14 13:29 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
2026-05-14 14:41 ` Daniel Palmer
2026-05-14 13:29 ` Willy Tarreau [this message]
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=agXOHVbclfZqbmTL@1wt.eu \
--to=w@1wt.eu \
--cc=daniel@thingy.jp \
--cc=david.laight.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.