From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53046 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1726382AbeHXNTZ (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 24 Aug 2018 09:19:25 -0400
From: David Howells <dhowells@redhat.com>
In-Reply-To: <CAJfpegvh_NoXxwMEhrmUdt5C4djMy=gKLBHqe-79XUWOi0j9eQ@mail.gmail.com>
References: <CAJfpegvh_NoXxwMEhrmUdt5C4djMy=gKLBHqe-79XUWOi0j9eQ@mail.gmail.com> <20180823223145.GK6515@ZenIV.linux.org.uk> <CALCETrVnwFGhZ0XWqyAsrOka43VohncrSd-gYgXXKxWHw+CmXg@mail.gmail.com> <24340.1535069316@warthog.procyon.org.uk> <CALCETrUOkkxYO__=ORad9XUJcW31ork6+kzo4-QHET5WSXfgYQ@mail.gmail.com> <20180824003105.GL6515@ZenIV.linux.org.uk> <184842E4-9368-463D-9131-D9A5F686C319@amacapital.net> <20180824031311.GM6515@ZenIV.linux.org.uk> <CALCETrVZKiQ=DJqnBiUEcMNypFjS=6PDmcjWoO0drbchs-KPzw@mail.gmail.com> <20180824060532.GG16817@thunk.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: dhowells@redhat.com, "Theodore Y. Ts'o" <tytso@mit.edu>,
        Andy Lutomirski <luto@amacapital.net>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>
Subject: Re: [git pull] new mount API
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <361.1535103931.1@warthog.procyon.org.uk>
Date: Fri, 24 Aug 2018 10:45:31 +0100
Message-ID: <362.1535103931@warthog.procyon.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Miklos Szeredi <miklos@szeredi.hu> 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