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
