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 <[email protected]> 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?
