Date: Mon, 24 May 1999 08:52:30 -0500 From: "Richard Seaman, Jr." <dick@tar.com> To: Peter Wemm <peter@netplex.com.au> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Bruce Evans <bde@zeta.org.au>, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: calcru and upages Message-ID: <19990524085229.A384@tar.com> In-Reply-To: <19990524001357.5311763@overcee.netplex.com.au>; from Peter Wemm on Mon, May 24, 1999 at 08:13:57AM %2B0800 References: <7757.927442621@critter.freebsd.dk> <19990524001357.5311763@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 24, 1999 at 08:13:57AM +0800, Peter Wemm wrote: > I'd also like to implement a proper clone(2) ala Linux. We have most of > the infrastructure in place already, using that and comparing with NetBSD's > take on the subject should be fairly useful in the end. The main > difference between clone(2) and rfork(2) is that clone() takes a stack > argument and is more specific about certain sharing semantics. At present > these are emulated via flags added into rfork's visibility, I think it > would be cleaner to just use a proper syscall interface onto fork1() rather > than bend rfork(2) even more. The function linux_clone() in linux_misc.c could be a starting place. Making that (or a modified version of it) a FreeBSD syscall would seem to do the trick. It calls rfork() instead of fork1(), but then rfork is implemented as a call to fork1, so the only difference is the interface. Probably the only real issue you have is whether the flags you pass in are FreeBSD rfork flags, or Linux flags that get translated into their equivalent FreeBSD flags internally before you call fork1(). The linux_clone() function obviously needs to take Linux flags. But, if your goal is to have a better interface than rfork(), you don't need to limit yourself to mimicing the linux clone() syscall. However, it seems to me that there are really only three reasons to have a "clone" call. One is for linux emulation, which we already have. Another is to facilitate porting linux apps. But, linux apps normally call the glibc version of clone, which wraps the linux clone(2) syscall. Its easy enough to create a userland (eg. libc) clone() call that wraps rfork (see the Linux threads port for an example implementation). The third is to create a better syscall interface for threading/ process creation than we have with rfork. I think that if FreeBSD is going to have really good "many to many" kernel/user threads there will probably need to be one or a few new syscalls for thread creation/thread management. IMO the best choice would be to think through what these calls should look like. I haven't had time to really work this through in my own mind, though. I suspect that the linux clone(2) syscall is not the best choice for this either. If you're going to work on this, and if you think it would help you, I'd try to find some time to jot down some of my (only partly formed) thoughts on what FreeBSD thread related syscalls might be helpful. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990524085229.A384>