Hi наб! On 2023-06-23 21:58, наб wrote: > Hi! > > After the bookworm update I've found that statfs.2 is shaded > [[deprecated]], citing > LSB has deprecated the library calls statfs() and fstatfs() and tells > us to use statvfs(3) and fstatvfs(3) instead. > > "LSB" doesn't appear to be, well, anything, inasmuch as > man-pages$ git grep LSB > Changes.old: Remove statement that LSB deprecates the functions > Changes.old: being deprecated in any of the LSB specs). Rather, LSB simply > Changes.old: doesn't specify these functions. (LSB 1.3 had a spec of > man2/statfs.2:LSB has deprecated the library calls > man3/gets.3:LSB deprecates > man5/elf.5:.B ELFDATA2LSB > man-pages$ git grep -i 'standard base' > > I, logically, know that LSB refers to the linux standard base, but I > don't see how it's relevant here. What's the stated reason? Is this part > of any publication? > > This function is not marked as deprecated in either glibc or musl, > and, indeed, on both implementations statvfs is just > return statfs_to_statvfs(statfs(...)); > > Normally, like who cares, and statvfs is the standard interface!, > but they carry disjoint data; they agree on > f_bavail f_bfree f_blocks f_bsize f_ffree f_files f_flag/f_flags f_frsize f_fsid f_namemax/f_namelen > but struct statvfs has > fsfilcnt_t f_favail; /* Number of free inodes for unprivileged users */ > to which glibc says > /* XXX I have no idea how to compute f_favail. Any idea??? */ > buf->f_favail = buf->f_ffree; > (this bug appears unnoted in the manual) and, much more importantly, > struct statfs has > __fsword_t f_type; /* Type of filesystem (see below) */ > which is removed in struct statvfs. > > (struct statvfs also has one field for f_fsid whereas it's two fields in > struct statfs, and this is truncated during the conversion; > this appears to just amount to a loss of entropy, so.) > > The standard fully allows having having the field there as an extension, > and thankfully both musl and glibc carry six ints of padding in > struct statvfs, so this could be done, but isn't. > > (Indeed, on glibc/Hurd struct statvfs already has an __f_type in there; > this should be an uncontroversial change.) > > Nevertheless, statfs() is shaded deprecated in favour of statvfs(), > contrary to all implementations, on shaky ground, and statvfs() cannot > actually replace statfs(). > > To this end, then: > * note that under Linux libcs, f_ffree = f_favail > * unshade statfs(2) as deprecated > (instead put a note at the end of the SYNOPSIS saying > "Use the standard interface (statvfs(3)) unless you need f_type." > or something to that effect?) > * post to glibc a patch renaming __f_type to f_type on Hurd > * post to glibc a patch replacing one of the __f_spares with f_type > * ibid. but musl > * once that lands, /then/ maybe mark statfs() as deprecated > (for weird types and nonportability) > * add f_type to statvfs(3) as "Filesystem type (Linux only, see > statfs(2) for possible values)" > > I've cooked up the libc patches but wanted to see if we're in agreement > here (and also wanted to have a list link to include in the messages). Seems important enough to answer promptly. I agree with you. Go ahead and propose a patch. I'll go back to my temporary retirement, and may take some time to apply the patch when you send it, though. <https://lore.kernel.org/linux-man/dc425a39-c16f-51b2-6940-2d4815b5cb73@xxxxxxxxx/T/#u> Best, Alex > > Best, > наб -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
