Re: [man-pages RFC PATCH] statx.2, open.2: document STATX_DIOALIGN

From: Eric Biggers
Date: Thu Jun 23 2022 - 13:56:05 EST


On Thu, Jun 23, 2022 at 10:27:19AM -0600, Andreas Dilger wrote:
> On Jun 23, 2022, at 10:02 AM, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
> >
> > On Thu, Jun 16, 2022 at 01:21:41PM -0700, Eric Biggers wrote:
> >> From: Eric Biggers <ebiggers@xxxxxxxxxx>
> >>
> >> @@ -244,8 +249,11 @@ STATX_SIZE Want stx_size
> >> STATX_BLOCKS Want stx_blocks
> >> STATX_BASIC_STATS [All of the above]
> >> STATX_BTIME Want stx_btime
> >> +STATX_ALL The same as STATX_BASIC_STATS | STATX_BTIME.
> >> + This is deprecated and should not be used.
> >
> > STATX_ALL is deprecated?? I was under the impression that _ALL meant
> > all the known bits for that kernel release, but...
>
> For userspace STATX_ALL doesn't make sense, and it isn't used by the kernel.
>
> Firstly, that would be a compile-time value for an application, so it
> may be incorrect for the kernel the code is actually run on (either too
> many or too few bits could be set).
>
> Secondly, it isn't really useful for an app to request "all attributes"
> if it doesn't know what they all mean, as that potentially adds useless
> overhead. Better for it to explicitly request the attributes that it
> needs. If that is fewer than the kernel could return it is irrelevant,
> since the app would ignore them anyway.
>
> The kernel will already ignore and mask attributes that *it* doesn't
> understand, so requesting more is fine and STATX_ALL doesn't help this.
>

What Andreas said. Note, this discussion really should be happening on my
standalone patch that fixes the documentation for STATX_ALL:
https://lore.kernel.org/r/20220614034459.79889-1-ebiggers@xxxxxxxxxx. I folded
it into this RFC one only so that it applies cleanly without a prerequisite.

- Eric