On Thu, 2019-11-21 at 08:10 +0000, David Howells wrote: > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > I was looking to use the read only bind mount as a template for > > reimplementing shiftfs when I discovered that you can't actually > > create a read only bind mount with the new API. The problem is > > that fspick() will only reconfigure the underlying superblock, > > which you don't want because you only want the bound subtree to > > become read only and open_tree()/move_mount() doesn't give you any > > facility to add or change options on the bind. > > You'd use open_tree() with OPEN_TREE_CLONE and possibly AT_RECURSIVE > rather than fspick(). fspick() is, as you observed, more for > reconfiguring the superblock. In the abstract, I think the concept of a configuration file descriptor with the, open add parameters and execution to fd, and optionally convert to representation or reconfigure in place is a very generic one. If we did agree to do that for bind mounts as well, I wouldn't overload the existing logic, I'd lift it up to the generic level, probably by hooking the execution parts, and make superblock and bind two implementations of it. It would basically be 3 system calls: configopen, configparam and configconvert although obviously with more appealing names. The reason for thinking like this is I can see it having utility in some of the more complex SCSI configuration operations we do today via a bunch of mechanisms including configfs that could more compactly be done by this file descriptor mechanism. I'd also note that this plethora of system calls you have could then go away: fspick itself would just become an open type to which the path file descriptor would then be a required parameter, as would open_tree and the missing mount_setattr would then just work. James
