Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]

[Andy Lutomirski]

> On Jul 12, 2018, at 9:58 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> 
>> On Thu, Jul 12, 2018 at 09:23:22AM -0700, Andy Lutomirski wrote:
>> 
>> As a straw man, I suggest:
>> 
>> fsconfigure(contextfd, ADD_BLOCKDEV, dfd, path, flags);
>> 
>> fsconfigure(contextfd, ADD_OPTION, 0, âfoo=barâ, flags);
> 
> Bollocks.  First of all, block device *IS* a fucking option.
> Always had been.  It's not even that it's passed as a separate
> argument for historical reasons - just look at NFS.  That argument
> is a detached part of options, parsed (yes, *parsed*) by filesystem
> in question in whatever way it prefers.

Fine, then generalize it. fsconfigure(context, ADD_FD, âsome fs-specific string explaining whatâs going onâ, fd);  The point being that there are tons of cases where the filesystem wants to identify some backing store by some device node, and it seems like we should support something along the lines of a modern *at interface.

If Iâm writing a daemon that deals with filesystems, I donât want an API that looks like do_god_knows_what(context, âfilesystem specific string that may contain a path to a device node or a network addressâ). That API will be a pain to use, since that opaque string may come from some random config file and I have no clue what it does. If I want to pass a device node or other object to a filesystem, I want to pass an fd (so I can use openat, SCM_CREDS, etc), and I want it to be crystal clear that Iâm passing some object in. And if I tell a filesystem to access the network, I want it to be entirely clear which network namespace is in use.

I realize that doing this right is tricky when there are lots of legacy filesystems that parse opaque strings. Thatâs fine. We can convert things slowly.