From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HXpIV-00032E-7D for qemu-devel@nongnu.org; Sat, 31 Mar 2007 21:55:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HXpIT-000320-Dc for qemu-devel@nongnu.org; Sat, 31 Mar 2007 21:55:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HXpIT-00031x-8s for qemu-devel@nongnu.org; Sat, 31 Mar 2007 20:55:57 -0500 Received: from grayson.netsweng.com ([207.235.77.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HXpFa-0002z4-Sb for qemu-devel@nongnu.org; Sat, 31 Mar 2007 21:52:59 -0400 Date: Sat, 31 Mar 2007 21:52:12 -0400 (EDT) From: Stuart Anderson Subject: Re: [Qemu-devel] [PATCH] clone syscall fix In-Reply-To: <20070331192104.GC24690@networkno.de> Message-ID: References: <20070331192104.GC24690@networkno.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer Cc: qemu-devel@nongnu.org On Sat, 31 Mar 2007, Thiemo Seufer wrote: > Stuart Anderson wrote: >> >> Even though clone() and fork() are related, they don't seem to be close >> enough to allow a single routine to be used to implement both. With this >> patch, the LTP tests for clone now pass. > > But it still does the same, assuming VM_CLONE is set, except for passing > additional arguments to the host call. I'm not so sure that the VM_CLONE flag should control wether the new stack is set up or not. There are tests for newsp == NULL inside that block anyway. The LTP certainly tests combination for which the do_fork() code doesn't work. > Passing untranslated regs looks > like a bug to me, I'm unsure about the tls_val. Hmm, could be, but that's the way it is in the current code. I think more testing on additional combination sof target &host will be needed. >> It may be possible to fold this back into do_fork(), but this just seemed to >> be a little bit more straightforward. > > Since Linux's fork() is just a specialcase of clone() this should be > done eventually. I'll try just dropping do_fork completely, and see if this new do_clone() works for the fork case also. If so, then that effectively folds the changes back into do_fork(), and more closely resembles that non-emulated case of fork() being implemnted on top of clone( anyway. Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149