Re: [PATCH 1/6] vfs: create vfs helper vfs_tmpfile()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 16, 2017 at 12:19 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> On Mon, Jan 16, 2017 at 1:00 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Sun, Jan 15, 2017 at 2:57 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>>> Factor out some common vfs bits from do_tmpfile()
>>> to be used by overlayfs for concurrent copy up.
>>
>> I'm wondering whether the vfs helper should do everything except the
>> path lookup and the open: d_alloc(), ->tmpfile() and setting
>> I_LINKABLE.   This will also aid in doing a ->tmpfile() for overlayfs.
>>
>
> I started with that, but slowly trimmed it down to this minimal version.
> First, mnt_want_write() can't be in there.
> Then dentry * return value would be a strange deviation from other vfs_ helpers.

What about lookup_one_len()?  It's not called vfs_something but that's
beside the point, I think.

> Lastly, all the open related operations are already performed by
> ovl_path_open() and I did not want to make an exception,
> so I resorted to doing d_alloc in ovl_alloc_tmpfile(), which becomes
> a drop-in replacement for ovl_lookup_temp() and set LINKABLE in
> ovl_link_tmpfile(), which becomes a drop-in replacement for ovl_do_rename().

The logical place to set I_LINKABLE is in vfs_tmpfile().  You are
arguing about overlayfs code structure, but that's mostly irrelevant
when doing a new vfs interface.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux