> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
