From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (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 800DB3C8C65 for ; Thu, 14 May 2026 14:20:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.126.157 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778768415; cv=none; b=gF9QxjyFVmC3G2zuAMUn4ujIBDswMBzqKmgaFxgOspEiIEDFGysZQS5dI2n8yRpYBPctEkTFRhKmXuYCZdhVYLDTvXCg1nbMo1nKfUZIPsLOCmFJ3+M4GOz/DCrGlhTFkTvYRo2y/IGwb6PDRXFv36hw4FhcZFG+Rqf2pNTak1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778768415; c=relaxed/simple; bh=XpK7tdbfZjqQWqKNJFwD9qzpTM3Xq+O92m2HKmgIsuQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qd7IwUV/RuKgUYj2nGAz0wgegKM7/YG4RbLpj2ugID2mEsyaAU2i/b+JVq3yuJ7AE76FzHfIKcFjNru2IMp12r/uOH+5uoaqMwgcS5xanWB4NiWPXVMFy+ypLM6HnDC+dUfsYYB5ghJLr4z0G3mE1kvnzYWDwHkTnrnr+cS9YEw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net; spf=pass smtp.mailfrom=weissschuh.net; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b=IANmkBN5; arc=none smtp.client-ip=159.69.126.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="IANmkBN5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1778768408; bh=XpK7tdbfZjqQWqKNJFwD9qzpTM3Xq+O92m2HKmgIsuQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IANmkBN5K1r9/PuF75434PB1UiwSpB+eZNoF0HCOYW6iD/YcPhHz2Ocw/CgC8liZV HzPw8pQ4f4d+bQ+4rVf63Zm2ZP+l8R7ZP6nlKMYWeEBL9SP5eav9guls7eX/qHxTY3 eXOLaqeTmBScgEMSXgJjM00gZtd5E0pJe6HFTqRg= Date: Thu, 14 May 2026 16:20:07 +0200 From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Daniel Palmer Cc: w@1wt.eu, david.laight.linux@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/3] tools/nolibc: Add statfs() Message-ID: <96c1a48a-657d-4916-a5ec-155485aea4ea@t-8ch.de> References: <20260507090353.356764-1-daniel@thingy.jp> <20260507090353.356764-3-daniel@thingy.jp> <7afa6d33-1673-4766-b939-301597e675ed@t-8ch.de> <17ef96e0-2cc3-4076-907d-7a8536c92dcb@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 2026-05-14 22:05:37+0900, Daniel Palmer wrote: > Hi Thomas, > > On Thu, 14 May 2026 at 21:40, Thomas Weißschuh wrote: > > > > On 2026-05-14 21:28:19+0900, Daniel Palmer wrote: > > > On Thu, 14 May 2026 at 20:42, Thomas Weißschuh 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 > > > > > +#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 #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