On Wed, 2024-02-21 at 18:49 +0800, WANG Xuerui wrote: > > On 2/21/24 18:31, Xi Ruoyao wrote: > > On Wed, 2024-02-21 at 14:31 +0800, Xi Ruoyao wrote: > > > On Wed, 2024-02-21 at 14:09 +0800, WANG Xuerui wrote: > > > > > > > - just restore fstat and be done with it; > > > > - add a flag to statx so we can do the equivalent of just fstat(fd, > > > > &out) with statx, and ensuring an error happens if path is not empty in > > > > that case; > > > It's worse than "just restore fstat" considering the performance. Read > > > this thread: > > > https://sourceware.org/pipermail/libc-alpha/2023-September/151320.html > > Hmm, but it looks like statx already suffers the same performance issue. > > And in this libc-alpha discussion Linus said: > > > > If the user asked for 'fstat()', just give the user 'fstat()'. > > > > So to me we should just add fstat (and use it in Glibc for LoongArch, only > > falling back to statx if fstat returns -ENOSYS), or am I missing something? > > Or we could add a AT_STATX_NULL_PATH flag and mandate that `path` must > be NULL if this flag is present -- then with simple checks we could have > statx(fd, NULL, AT_STATX_NULL_PATH, STATX_BASIC_STATS, &out) that's both > fstat-like and fast. But then to take the advantage in Glibc fstat() implementation, we'll need to try AT_STATX_NULL_PATH first, then check for EFAULT (not ENOSYS!) and fall back to AT_EMPTY_PATH. The EFAULT checking seems nasty to me... -- Xi Ruoyao <xry111@xxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
