Roland McGrath [roland@xxxxxxxxxx] wrote: | Some userland debugging things and so forth like to look at the clone_flags | argument, so that is kept simpler for them if it stays in a register | (i.e. its own argument) rather than a user pointer fetch for that argument. | Any problem with: | | sys_clone3(unsigned long clone_flags, | struct clone_struct __user *cs, pid_t __user *pids) | | ? My only concern is the support of 64-bit clone flags on 32-bit architectures. We would need an additional register/parameter, clone_flags_high ? Also, hopefully we won't need more than 64 flags, but if we do, the plan AFACIT, was that we could use one of the reserved fields. | | That also has the side benefit that instead of non-ia64 users forever | asking, "Why is it clone3 when there is no clone2?" you can instead pretend | that it follows the "clone3 because it takes three arguments" convention. ;-) | | Btw, IMHO "struct foo_struct" is one of the lamest naming conventions ever. | How about "struct clone_args"? Sure :-) In earlier version of patches I had mixed up clone_struct and clone_arg in comments/descriptions and cleaned up in this version. | | Also, if you were to replace: | | u64 child_stack; | | with: | | u64 child_stack_base; | u64 child_stack_size; | | and use in sys_clone3 (for most arch's): | | child_stack_ptr = kcs.child_stack_base + kcs.child_stack_size; | | then the same clone3 interface would cover ia64 as well. Ok | | | Thanks, | Roland _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
