[RFC][v7][PATCH 8/9]: Define clone2() syscall
torvalds at linux-foundation.org
Tue Sep 29 15:11:03 PDT 2009
On Tue, 29 Sep 2009, H. Peter Anvin wrote:
> That's not the main issue here, though. The main issue is that the
> prototype of the function now depends on one of its arguments
Ok, I agree with that. The kernel side is easy (we have magic calling
conventions there and need to turn registers into arguments anyway before
you get to the shared code), but your point about the user side prototype
However, that could easily be handled by just having a extended_clone()
prototype that then sets the CLONE_EXTINFO (or whatever) bit in the flags.
I think most of the time the clone() stuff needs special user-level
wrappers anyway to handle the stack setup etc, no?
In other words, what I'd suggest we could do is
- the kernel "do_fork()" interface would be made to have the "extended"
format by default - so the _kernel_ never has two formats in its
- the "sys_clone()" system call, that already needs to munge the user
mode registers into the "do_fork()" format, would be the one that
recognizes the new flag and copies the extended data from user mode
memory to the extended info mode.
Then each architecture would need to update it's "sys_clone()" function to
take advantage of the new extended format, but that's something that the
new system call would have had to do anyway, so that's not an added burden
in any way.
I don't feel horribly strongly about this, and as far as I'm concerned
it's fine to also do it as a new system call too (we already have 'fork()'
and 'vfork()' as special case interfaces to do_fork() - the new 'extended
clone' would be no different).
I just think that Roland is correct that if the new extended fork handles
the "no new info" case itself _anyway_, then there is no upside to making
it a new system call, since the complexity is the same as just extending
the old one.
More information about the Containers