Re: [PATCH 11/11][v15]: Document sys_eclone

[Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

Albert Cahalan [acahalan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] 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