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
