Date: Fri, 28 Mar 2014 03:32:05 -0600 (MDT) From: Chris Torek <torek@elf.torek.net> To: freebsd-hackers@freebsd.org, julian@freebsd.org, kib@freebsd.org Subject: Re: slight problem with r254457 (kthread_add fix) Message-ID: <201403280932.s2S9W5s3073181@elf.torek.net> In-Reply-To: <53351E96.1000608@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403280932.s2S9W5s3073181>