Ref: https://lwn.net/Articles/896153/ On Wed, 31 Aug 2022 at 04:57, Yu-Li Lin <yulilin@xxxxxxxxxx> wrote: > > On Fri, Nov 13, 2020 at 2:54:46PM +0100, Miklos Szeredi wrote: > > > > On Fri, Nov 13, 2020 at 1:28 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, Nov 13, 2020 at 11:52:09AM +0100, Miklos Szeredi wrote: > > > > > > > It's the wrong interface, and we'll have to live with it forever if we > > > > go this route. > > > > > > > > Better get the interface right and *then* think about the > > > > implementation. I don't think adding ->atomic_tmpfile() would be that > > > > of a big deal, and likely other distributed fs would start using it in > > > > the future. > > > > > > Let me think about it; I'm very unhappy with the amount of surgery it has > > > taken to somewhat sanitize the results of ->atomic_open() introduction, so > > > I'd prefer to do it reasonably clean or not at all. > > > > The minimal VFS change for fuse to be able to do tmpfile with one > > request would be to pass open_flags to ->tmpfile(). That way the > > private data for the open file would need to be temporarily stored in > > the inode and ->open() would just pick it up from there without > > sending another request. Not the cleanest, but I really don't care as > > long as the public interface is the right one. > > > > Thanks, > > Miklos > > Resurrecting this old thread. Is there a conclusion on the addition of atomic_tmpfil() or vfs changes? > > Thanks, > Yu-Li Lin
