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@gmail.com/T/#u>

Best,
Alex

> 
> Best,
> наб

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5