Quoting Pavel Emelyanov ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: > > Quoting Cedric Le Goater ([EMAIL PROTECTED]): > >> to be more precise : > >> > >> long sys_clone_something(struct clone_something_args args) > >> > >> and > >> > >> long sys_unshare_something(struct unshare_something_args args) > >> > >> The arg passing will be slower bc of the copy_from_user() but we will > >> still have the sys_clone syscall for the fast path. > >> > >> C. > > > > I'm fine with the direction you're going, but just as one more option, > > we could follow more of the selinux/lsm approach of first requesting > > clone/unshare options, then doing the actual clone/unshare. So > > something like > > > > sys_clone_request(extended_64bit_clone_flags) > > What if we someday hit the 64-bit limit? :) > > > sys_clone(usual args) > > > > or > > > > echo pid,mqueue,user,ipc,uts,net > /proc/self/clone_unshare > > clone() > > Well, this is how sys_indirect() was intended to work. Nobody > liked it, so I'm afraid this will also not be accepted.
I would have thought sys_indirect would be disliked because it looks like an ioctl type multiplexor. Whereas sys_clone_request() or /proc/self/clone_unshare simply sets arguments in advance, the way /proc/self/attr/current does. -serge _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
