Re: [git pull] new mount API

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

 



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




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

  Powered by Linux