On Sat, Jun 02, 2018 at 04:09:14AM +0100, Al Viro wrote: > On Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote: > > Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > Instead of overloading this on open having a specific syscalls just > > > > seems like a much saner idea. > > > > > > It's not just mount API; these can be used independently of that. > > > Think of the uses where you pass those to ...at() and you'll see > > > a bunch of applications of that thing. > > > > I kind of agree with Christoph on this point. Yes, you can use the resultant > > fd for other things, but that doesn't mean it has to be obtained initially > > through open() or openat() rather than, say, a new pick_mount() syscall. > > > > Further, having more parameters available gives us the opportunity to change > > the settings on any mounts we create at the point of creation. > > open_subtree(int dirfd, const char *pathname, int flags), then? How would > flags be interpreted? What I see mapping at that thing is > * equivalent of O_PATH open > * clone subtree, O_PATH open root > * clone one mount, O_PATH open root > and apparently you want to add (orthogonal to that) > * make shared/slave/private/unbindable > * ditto with recursion? > * same for nodev/nosuid/noexec/noatime/nodiratime/relatime/ro/? > as well as usual AT_... flags (empty path, follow) > > Choose the encoding... _If_ I'm interpreting that correctly, that should be something like a bitmap of attributes to modify + values to set for each. Let's see - propagation 1 + 2 bits nodev 1 + 1 noexec 1 + 1 nosuid 1 + 1 ro 1 + 1 atime 1 + 3 That's 15 bits. On top of that, we have 1 bit for "clone or original" and 1 bit for "recursive or single-mount". As well as AT_EMPTY_PATH, and AT_NO_AUTOMOUNT (inconvenient, since these are fixed bits). In principle, that does fit into int, with some space to spare... Is that what you have in mind? -- 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
