From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12504 invoked from network); 24 Jun 2023 04:39:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2023 04:39:56 -0000 Received: (qmail 1492 invoked by uid 550); 24 Jun 2023 04:39:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1460 invoked from network); 24 Jun 2023 04:39:51 -0000 Date: Sat, 24 Jun 2023 06:39:39 +0200 From: Szabolcs Nagy To: =?utf-8?B?0L3QsNCx?= Cc: musl@lists.openwall.com Message-ID: <20230624043939.GC3630668@port70.net> Mail-Followup-To: =?utf-8?B?0L3QsNCx?= , musl@lists.openwall.com References: <2a5yr4pg5a2lt5enykfhqezpggsdhkn6j2cpslls5n26qaffss@jz5pftqutx6t> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <2a5yr4pg5a2lt5enykfhqezpggsdhkn6j2cpslls5n26qaffss@jz5pftqutx6t> Subject: Re: [musl] [PATCH] [f]statvfs: allocate spare for f_type * =D0=BD=D0=B0=D0=B1 [2023-06-23 22:36:= 11 +0200]: > 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. >=20 > Instead, allocate one of the six spares to f_type, > copied directly from struct statfs. > This then becomes a small extension to the standard interface on Linux, > 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(). >=20 > 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. >=20 > Link: https://lore.kernel.org/linux-man/f54kudgblgk643u32tb6at4cd3kkzha6h= slahv24szs4raroaz@ogivjbfdaqtb/t/#u fwiw this looks good to me assuming the glibc patch gets accepted: https://patchwork.sourceware.org/project/glibc/patch/169a6ec2a9957495275964= afd0697fa3aea1c6b6.1687552604.git.nabijaczleweli@nabijaczleweli.xyz/ > --- > include/sys/statvfs.h | 3 ++- > src/stat/statvfs.c | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) >=20 > diff --git a/include/sys/statvfs.h b/include/sys/statvfs.h > index 57a6b806..71d9d1f9 100644 > --- a/include/sys/statvfs.h > +++ b/include/sys/statvfs.h > @@ -23,7 +23,8 @@ struct statvfs { > unsigned long f_fsid; > #endif > unsigned long f_flag, f_namemax; > - int __reserved[6]; > + unsigned int f_type; > + int __reserved[5]; > }; > =20 > int statvfs (const char *__restrict, struct statvfs *__restrict); > diff --git a/src/stat/statvfs.c b/src/stat/statvfs.c > index bfbb5fee..bc12da8b 100644 > --- a/src/stat/statvfs.c > +++ b/src/stat/statvfs.c > @@ -39,6 +39,7 @@ static void fixup(struct statvfs *out, const struct sta= tfs *in) > out->f_fsid =3D in->f_fsid.__val[0]; > out->f_flag =3D in->f_flags; > out->f_namemax =3D in->f_namelen; > + out->f_type =3D in->f_type; > } > =20 > int statvfs(const char *restrict path, struct statvfs *restrict buf) > --=20 > 2.39.2