Skip site navigation (1)Skip section navigation (2)
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>