From: наб <nabijaczleweli@nabijaczleweli.xyz>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: linux-man@vger.kernel.org
Subject: [f]statfs(2) shaded as deprecated?
Date: Fri, 23 Jun 2023 21:58:49 +0200 [thread overview]
Message-ID: <f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb> (raw)
[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]
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).
Best,
наб
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2023-06-23 19:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 19:58 наб [this message]
2023-06-23 20:08 ` [f]statfs(2) shaded as deprecated? Alejandro Colomar
2023-06-23 21:00 ` [PATCH 1/2] statfs.2: unshade as deprecated, but direct to statvfs(3) наб
2023-06-23 21:00 ` [PATCH 2/2] statvfs.3: note f_favail = f_ffree on Linux наб
2023-06-24 0:39 ` [PATCH v2 " наб
2023-07-05 13:57 ` Tom Schwindl
2023-07-08 17:11 ` Alejandro Colomar
2023-07-08 20:01 ` [PATCH v3 " наб
2023-07-15 13:41 ` Alejandro Colomar
2023-07-18 11:43 ` [PATCH v2 " Alejandro Colomar
2023-07-18 11:48 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f54kudgblgk643u32tb6at4cd3kkzha6hslahv24szs4raroaz@ogivjbfdaqtb \
--to=nabijaczleweli@nabijaczleweli.xyz \
--cc=alx.manpages@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).