Albert Cahalan [acahalan@xxxxxxxxx] wrote: | Not that one couldn't cram | things into the old system call, but that would involve changing | the meaning of at least one parameter based on a flag. (eeew) My understanding was that extending eclone() in the future using a flag to determine the size would get the same response. Maybe I misunderstood that, but when Peter proposed that we use the 'args_size' - it looked logical to me. Sure such interfaces are not common, but I did not see any response/objections to it. http://lkml.org/lkml/2009/10/14/497 | | I'm suggesting that you not copy the struct as one blob, or at | least not expect to do so for future extensions to eclone. You | can read the flags, use that to determine struct size, and then | read the rest of the struct. Alternately you can pass 32 more flags | as a 5th syscall argument. | | I'm not so sure we need 96 flag bits, but OK. They can all go | in the struct if you like, or they can all go in the arguments. | FWIW, I happen to think that both kernel and user code will | be less ugly if all of the flags fit in 64 bits. C doesn't provide | a 96-bit integer type. We wanted to leave the original 32-bits of clone-flags as the first parameter to avoid confusing the application writers. http://lkml.org/lkml/2009/10/14/13 We do not anticipate needing 64 more flags - we may have several independent calls to unshare/clone new namespaces. We can treat the higher 32-bits as a "reserved" field for now and not worry about using all 96-bits for now. Sukadev _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
