Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > Also you can't currently directly create a bind mount from userspace as you > > can only bind from another path point - which you may not be able to access > > (either by permission failure or because it's not in your mount namespace). > > > > Are you trying to preserve the magic bind semantics with the new API? No, I'm pointing out that you can't emulate this by doing a bind mount from userspace if you can't access the thing you're binding from. Now, we could create a syscall that just picks up an extant superblock using a device and attaches it to a mount for you, but that would have to be at least partially parameterised - which would be very fs-dependent - so that it can know whether or not you're allowed to create another mount to that sb. What you're talking about is emulating sget() in userspace - when we have to do it in the kernel anyway if we still offer mount(2). David -- 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
