From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 09:32:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34CFEDB7; Fri, 28 Mar 2014 09:32:14 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2B0A30A; Fri, 28 Mar 2014 09:32:13 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2S9W5NH073182; Fri, 28 Mar 2014 03:32:05 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id s2S9W5s3073181; Fri, 28 Mar 2014 03:32:05 -0600 (MDT) (envelope-from torek) Date: Fri, 28 Mar 2014 03:32:05 -0600 (MDT) From: Chris Torek Message-Id: <201403280932.s2S9W5s3073181@elf.torek.net> To: freebsd-hackers@freebsd.org, julian@freebsd.org, kib@freebsd.org Subject: Re: slight problem with r254457 (kthread_add fix) In-Reply-To: <53351E96.1000608@freebsd.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 28 Mar 2014 03:32:06 -0600 (MDT) X-Mailman-Approved-At: Fri, 28 Mar 2014 11:32:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 09:32:14 -0000 >this is the reason that I originally made the new thread 'fork' >off an old one (back in 2000 I think it was.. I was in Budapest I >remember.), anyway I didn't want to be bothered with the internal >contents of stuff I didn't understand on processors I didn't >know, and the rule was "no FPU in the Kernel", so it was "safe" >(ish). > >I did make a mental note that if there were ever problems with >this then we should write a machine dependent function to set up >a new thread context ... This is kind of a mess though, since every OTHER process/thread creation (except the initial ones in proc0/thread0) works by cloning. So you end up with some kind of test (a flag, or "old thread == NULL", or whatever) somewhere, or duplicated code. (Overall, I like the "make MD code clean things up" method better. Depending on thread0 state is pretty hacky. It's just more work to check everything.) (I remember when someone, I think it may have been Mike Karels, shuffled all the members of "struct proc" around so that we could use the bcopy-some, bzero-some method to speed up fork(). It's a hack too, but it's a nice one, and it's still in there, in modified form. :-) ) Chris