From patchwork Fri Jun 23 20:37:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?0L3QsNCx?= X-Patchwork-Id: 1799160 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=HgW9jZtv; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4QnpvT1tVLz20XB for ; Sat, 24 Jun 2023 06:37:25 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3B2C33857707 for ; Fri, 23 Jun 2023 20:37:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B2C33857707 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687552643; bh=LVGL6CLRvXLM4t38ScJ+kmfQmuPBHWYDp11idoheBKM=; h=Date:Cc:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=HgW9jZtvgv7g2wLxCUuVcSw/WynFj56IeFRa+wTTUQXmv1sQdPfyhugPDQOpXgtJ+ 3cxvLwTo4P26mt/aUCcg2Vh19hfAiqrQliI9Tt8vAe7m4XTivdgaNnSxMOzr6cTvmw WYdvEYsDv5AQM9leKjx/t3FwIGeR5EytVkl3ogYI= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from tarta.nabijaczleweli.xyz (unknown [139.28.40.42]) by sourceware.org (Postfix) with ESMTP id 606A93858C2F for ; Fri, 23 Jun 2023 20:37:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 606A93858C2F Received: from tarta.nabijaczleweli.xyz (unknown [192.168.1.250]) by tarta.nabijaczleweli.xyz (Postfix) with ESMTPSA id C406E1294 for ; Fri, 23 Jun 2023 22:37:03 +0200 (CEST) Date: Fri, 23 Jun 2023 22:37:02 +0200 Cc: libc-alpha@sourceware.org Subject: [PATCH 2/2] linux: statvfs: allocate spare for f_type Message-ID: <169a6ec2a9957495275964afd0697fa3aea1c6b6.1687552604.git.nabijaczleweli@nabijaczleweli.xyz> References: <0fd9629f7215d1c43968a900238d03d9275a74fa.1687552604.git.nabijaczleweli@nabijaczleweli.xyz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0fd9629f7215d1c43968a900238d03d9275a74fa.1687552604.git.nabijaczleweli@nabijaczleweli.xyz> User-Agent: NeoMutt/20230517 X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_INFOUSMEBIZ, MISSING_HEADERS, PDS_RDNS_DYNAMIC_FP, RDNS_DYNAMIC, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: =?utf-8?b?0L3QsNCxIHZpYSBMaWJjLWFscGhh?= From: =?utf-8?b?0L3QsNCx?= Reply-To: =?utf-8?b?0L3QsNCx?= Errors-To: libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org Sender: "Libc-alpha" This is the only missing part in struct statvfs. The LSB calls [f]statfs() deprecated, and its weird types are definitely off-putting. However, its use is required to get f_type. Instead, allocate one of the six spares to f_type, copied directly from struct statfs. This then becomes a small glibc extension to the standard interface on Linux and the Hurd, instead of two different interfaces, one of which is quite odd due to being an ABI type, and there no longer is any reason to use statfs(). The underlying kernel type is a mess, but all architectures agree on u32 (or more) for the ABI, and all filesystem magicks are 32-bit integers. Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb/t/#u Signed-off-by: Ahelenia Ziemiańska --- sysdeps/unix/sysv/linux/bits/statvfs.h | 6 ++++-- sysdeps/unix/sysv/linux/internal_statvfs.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/sysdeps/unix/sysv/linux/bits/statvfs.h b/sysdeps/unix/sysv/linux/bits/statvfs.h index 8dfb5ce761..cf98460e00 100644 --- a/sysdeps/unix/sysv/linux/bits/statvfs.h +++ b/sysdeps/unix/sysv/linux/bits/statvfs.h @@ -51,7 +51,8 @@ struct statvfs #endif unsigned long int f_flag; unsigned long int f_namemax; - int __f_spare[6]; + unsigned int f_type; + int __f_spare[5]; }; #ifdef __USE_LARGEFILE64 @@ -71,7 +72,8 @@ struct statvfs64 #endif unsigned long int f_flag; unsigned long int f_namemax; - int __f_spare[6]; + unsigned int f_type; + int __f_spare[5]; }; #endif diff --git a/sysdeps/unix/sysv/linux/internal_statvfs.c b/sysdeps/unix/sysv/linux/internal_statvfs.c index 6a1b7b755f..112d3c241a 100644 --- a/sysdeps/unix/sysv/linux/internal_statvfs.c +++ b/sysdeps/unix/sysv/linux/internal_statvfs.c @@ -57,6 +57,7 @@ __internal_statvfs (struct statvfs *buf, const struct statfs *fsbuf) buf->__f_unused = 0; #endif buf->f_namemax = fsbuf->f_namelen; + buf->f_type = fsbuf->f_type; memset (buf->__f_spare, '\0', sizeof (buf->__f_spare)); /* What remains to do is to fill the fields f_favail and f_flag. */ @@ -99,6 +100,7 @@ __internal_statvfs64 (struct statvfs64 *buf, const struct statfs64 *fsbuf) buf->__f_unused = 0; #endif buf->f_namemax = fsbuf->f_namelen; + buf->f_type = fsbuf->f_type; memset (buf->__f_spare, '\0', sizeof (buf->__f_spare)); /* What remains to do is to fill the fields f_favail and f_flag. */