Date: Mon, 20 Oct 1997 14:12:03 +0200 From: Martin Cracauer <cracauer@cons.org> To: Stefan Arentz <stefan.arentz@luna.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Linux Emulation - clone() Message-ID: <19971020141203.20645@cons.org> In-Reply-To: <19971018222208.49710@kalkoen.sateh.com>; from Stefan Arentz on Sat, Oct 18, 1997 at 10:22:08PM %2B0200 References: <19971018222208.49710@kalkoen.sateh.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <19971018222208.49710@kalkoen.sateh.com>, Stefan Arentz wrote: > I'm trying to implement the linux clone() system call in 2.2.2. Good news :-) > It > looks like this can be done with the FreeBSD rfork call except that > Linux also allows you to set the user stack pointer for the new > process. > > pid_t clone(void *sp, unsigned long flags) > > I'm still reading 'The design and implementation of the 4.4BSD > operating system' to get a clue about where to setup the stack > pointer, but it's still a big mystery to me ;) The information in the book is outdated and doesn't apply to FreeBSD anymore. About a month ago, the semantics to FreeBSD's rfork system call has been changed. The former behaviour left you with identical stacks in parent and child. The new behaviour is to always copy the stack to a new location, which is chosen by the system call. Check the mail archives of -current from Sep, 18-20. To emulate the Linux call, you can probably do it like this (I assume the caller already allocated space for the stack): - in the clone call, put the address of the user-supplied stack on the stack. - call rfork - in the new child, do a return instruction from assembly, so that the stack pointer now points to the user's location. This should even work before and after the behaviour change I noted above, since you don't use any rfork-supplied stack at all. In a similar thread John Dyson noted that you might want to hold signals until the new stack is in use in the child. See -hackers archives from Sep, 16. I hope this helps, but please note that I'm speaking from theory, never tangled with this myself. Aren't there some other problems, BTW? I know Linux planned to implement clone flags so that process IDs are shared. This is needed to be Posix threads compliant with plain fork/clone-based thread packages. And how are user's of clone() supposed to know how large the stack region should be? If I'm not mistaken, the current FreeBSD rfork implementation has grow-on-demand stacks as any usual process. It seems to me this is an ugly performance hack to save the kernel from allocating some space (but not from copying the contents, so it's probably not worth the effort). comp.prorgramming.threads is full of people claiming Linuxthreads can launch threads x-times faster than any other system. Oh well... Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ BSD User Group Hamburg/Germany http://www.bsdhh.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971020141203.20645>