On Fri, Aug 24, 2018 at 9:51 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Aug 24, 2018 at 09:25:58PM +0200, Miklos Szeredi wrote: >> On Fri, Aug 24, 2018 at 7:43 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >> > On Fri, Aug 24, 2018 at 10:10 AM, David Howells <dhowells@xxxxxxxxxx> wrote: >> >> Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >> >> >>> Hmm. Is it that case in the current patchset that you can do CMD_CREATE and >> >>> reconfigure the result and some *other* existing mount will change? If so, >> >>> that’s rather unfriendly to users. >> >> >> >> The default behaviour has to be the same as mount(2). >> >> This is rubbish. Anyone wanting the mount(2) behavior can use mount(2). >> >> About exclusive create: can't we just look at the active reference >> count of the superblock returned by ->get_tree() (if it's one, we are >> the only users, i.e. the create was exclusive)? > > Let me get it straight - your default behaviour would routinely refuse NFS mount > simply because somebody has already mounted from the same server? Yeah, bad idea. > The main reason for keeping existing semantics is very, very simple: nobody > has offered a sane replacement. For all warts (and I admit that policy > re sharing turned out to be rather bad for any kind of situation with > non-cooperative admins - in partial defense, back in 2000/2001 when it was > done anybody talking about something like userns would've gotten laughed at, > for a lot of good reasons) mount(2) semantics is defined *and* needs to be > supported anyway. > > All suggested "better replacements" were bloody problematic. Sure, we'll need > to sort that out, but again, why the hell tie that to untangling the sodding > mount(2) ABI? What I was primarily suggesting is pretty simple, yet nobody seems to get it: name the current behavior what it is: legacy. Call this op e.g. CMD_LEGACY_FIND_OR_CREATE. It means "you're using the shiny new API, but be warned: we'll still use the old and stinky way to get the super block". We'll hopefully untangle it, sooner rather than later, and then have ops with less scary names. Thanks, Miklos
