Re: [git pull] new mount API

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

 



Miklos Szeredi <miklos@xxxxxxxxxx> wrote:

> I'm not against merging this patchset (have nits about resuing the
> MS_* constants for the new API that I've complained about, but that's
> really easy to fix before -final),

Can you send me a patch that does what you want here?  They're only used by
fsmount() for creating a vfsmount and not used for the superblock creation or
reconfiguration.

> but it may make sense to differentiate the legacy behavior from a saner one
> from the very start.  I.e. rename FSCONFIG_CMD_CREATE

I would suggest leaving it as-is and add an FSCONFIG_CMD_CREATE_EXCLUSIVE.

> to something implying it's actually *not* a create in exclusive sense that
> one would first imply (and yeah, we have creat() and O_CREAT, which don't
> imply exclusivity, yet they at least have clear semantics that current super
> block creation does definitely not).

The problem is that "exclusivity" isn't necessarily an easy thing to define.
Take nfs4 and btrfs for example.  They creating a backing superblock that the
actual node is derived from (though in different ways).  How do you define
what "exclusive" means in their case?

David



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux