> On Tue, Dec 12, 2023 at 7:44 PM Kent Overstreet <[email protected]> > wrote: > > > > On Tue, Dec 12, 2023 at 09:15:29AM -0800, Frank Filz wrote: > > > > On Tue, Dec 12, 2023 at 10:10:23AM +0100, Donald Buczek wrote: > > > > > On 12/12/23 06:53, Dave Chinner wrote: > > > > > > > > > > > So can someone please explain to me why we need to try to > > > > > > re-invent a generic filehandle concept in statx when we > > > > > > already have a have working and widely supported user API that > > > > > > provides exactly this functionality? > > > > > > > > > > name_to_handle_at() is fine, but userspace could profit from > > > > > being able to retrieve the filehandle together with the other > > > > > metadata in a single system call. > > > > > > > > Can you say more? What, specifically is the application that > > > > would want > > > to do > > > > that, and is it really in such a hot path that it would be a > > > > user-visible improveable, let aloine something that can be actually be > measured? > > > > > > A user space NFS server like Ganesha could benefit from getting > > > attributes and file handle in a single system call. > > > > > > Potentially it could also avoid some of the challenges of using > > > name_to_handle_at that is a privileged operation. > > > > which begs the question - why is name_to_handle_at() privileged? > > > > AFAICT, it is not privileged. > Only open_by_handle_at() is privileged.
Ah, that makes sense. I'm a consumer of these interfaces, not so much in the kernel these days. Ganesha depends on open_by_handle_at as well, so requires privilege to do handle stuff with kernel file systems. In any case, Ganesha could easily benefit from a savings of system calls. What would also be handy is a read directory with attributes that gave the statx results for each entry. Frank
