Re: [git pull] new mount API

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

 



On Thu, Aug 23, 2018 at 5:08 PM, David Howells <dhowells@xxxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
>> Has anything been done to ensure that the behavior when doing
>> FSCONFIG_CMD_CREATE against an already-mounted block device is
>> reasonable?
>
> For the moment, I've left it as the same behaviour as for mount(2) since
> mount(2) now uses the same mechanism internally and we aren't permitted to
> break userspace.
>
> I would like to add at least one flag to stipulate that, in the case of an
> incompatible collision, you can get a failure - but defining what is meant by
> incompatible isn't necessarily trivial, and would vary by filesystem *and* the
> LSM.
>
> However, I don't want to start reengineering everything this close to the
> merge window and we don't really need it immediately.
>

The problem is that, once this ends up merged, then we're kind of
stuck with it, too.  It would be a bit sad if your better proposal for
handling nfs and instantiation of filesystems in general were added in
the next release and then we end up with the current
FSCONFIG_CMD_CREATE as a permanently supported but non-preferred
option.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux