| Message ID | 169a6ec2a9957495275964afd0697fa3aea1c6b6.1687552604.git.nabijaczleweli@nabijaczleweli.xyz |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] hurd: statvfs: __f_type -> f_type | expand |
* наб via Libc-alpha: > 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 I think the caller can check for f_type being zero to check if it has been written by glibc, so this does not require a new symbol version. The previous already initializes __f_spare to zero, and none of the magic values in <linux/magic.h> are zero. This should perhaps have a NEWS entry, though, and a test case. Thanks, Florian
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. */
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 <nabijaczleweli@nabijaczleweli.xyz> --- sysdeps/unix/sysv/linux/bits/statvfs.h | 6 ++++-- sysdeps/unix/sysv/linux/internal_statvfs.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-)