From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4389E282F1B for ; Thu, 14 May 2026 13:29:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778765347; cv=none; b=sv9SMouB3JiuVsxRUL8UlFC5ILqJuJR8e7AS/VgntUF0MYLdw4TuvfIev/4VUMg0b3YB4T/NT7T8krMSjYUu60mejn3ru8BN1iiOeyEnYGumt//pGI7NTYsEwsBnkLSpoIa2l1PXvQRzV+vIRQJRLkM2LLANSRLa+EEfYgUZmpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778765347; c=relaxed/simple; bh=0009xWbYw+iTc9CjIFrvKjMlj0VMTOVle9OcWVN9azo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RJ5FobO3QKcSFKoz13dXtEk6gfqvNGApl5+IwsUnNn9/AB50cgC0Kg4bLZlzTiPeCbSIFdgQ6C4h/a+RAaEm3qo4k6e6qHyY/M5/+SEdsMZCQ4fWl4BTxwVM+ujDvV3AglvgYyhlWqeOF4GbSjqClPBIEDUlDSLle5tkf0eW41c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=O029Eu03; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="O029Eu03" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1778765341; bh=4pi1ZiZxqxx/a8ptC+U0hjLXy4A7tjhGQHvMsSIxmJY=; h=From:Message-ID:From; b=O029Eu03lmRAOz5yrExOXMwflJgmIN61MdmXoDYfcsvf3GVysUY6uyRa6biksbluy ov1TkNfjC+xv5ZjGnx08h6pe4loVw8L0EJokF4VbbbitiBiU9j21tBw2wX6LnyAA8M ZeLa5moXe8y+Au2FAv0u4sp0/Qc0CaZ3PwJ0wwYw= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id C26A9C0ADB; Thu, 14 May 2026 15:29:01 +0200 (CEST) Date: Thu, 14 May 2026 15:29:01 +0200 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Daniel Palmer , david.laight.linux@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/3] tools/nolibc: Add statfs() Message-ID: References: <20260507090353.356764-1-daniel@thingy.jp> <20260507090353.356764-3-daniel@thingy.jp> <7afa6d33-1673-4766-b939-301597e675ed@t-8ch.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 > > + */ > > + > > +/* 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 > > +#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