On Mon, Jul 12, 2010 at 5:54 PM, Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> wrote: > 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. I doubt that. We extended clone via flags without trouble, increasing the number of parameters it took. We never had to change the meaning of a parameter though. Unfortunately we used up the last (sixth) free system call parameter. There is no way to cram in a pointer to a parameter struct unless we redefine one of the six existing parameters, which is yucky. For example, the stack pointer parameter could instead point at a struct if some "#define CLONE_EXT 0x80000000" is set. We've done worse I think, (mount?), but... So the distinction here is adding vs. redefining. You wouldn't need to redefine anything, since RAM space is plentiful. The old clone syscall can only be extended by redefining, because we've run out of registers. I must admit that the hack looks strangely appealing though, eliminating the need to wait for glibc or find alternatives. :-) > | 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 IMHO, having multiple flags fields is far more confusing. It's easier to document the high flag case ("This flag requires the eclone system call.") than to document multiple sets of incompatible flags for one system call. I always curse the nasty multi-flagged mmap interface whenever I use it. If you're going to be concerned with flags getting truncated via improper use of the syscall, then you should be at least as concerned with flags getting passed in the wrong place. For example, one might pass all flags (high and low) in the struct. Somebody else might pass all flags in the parameters. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
