Date: Tue, 5 Feb 2002 14:41:51 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Dan Eischen <eischen@vigrid.com>, bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call Message-ID: <Pine.BSF.4.21.0202051438340.87080-100000@InterJet.elischer.org> In-Reply-To: <200202052151.g15Lp4S30546@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan,
if you can apply the posted KSE changes,
then you can start working on fitting your call into the
test program. You should also alter the single function
cpu_export_context() in the kernel which is the in-kernel
version of the same call.
If you do that, you can start testing your stuff immediatly..
The test program is doing full KSE multithreading.
On Tue, 5 Feb 2002, Matthew Dillon wrote:
> I thought we were trying to avoid having to make any system calls on
> a userland thread context switch.
>
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
>
> :I've turned {get,set,swap}context into a system call after peter's
> :suggestion and it now looks similar to Solaris' getsetcontext. Ours is:
> :
> : int getsetcontext(ucontext_t *oucp, const ucontext_t *ucp);
> :
> :It's similar to sigprocmask. If oucp is null, then it behaves as
> :getcontext. If ucp is null, it behaves as setcontext. And if
> :both args are non-null, then it behaves as swapcontext. It returns
> :0 upon success, 1 if the context was swapped (like longjmp), otherwise
> :returns with errno set accordingly. Some glue is needed in libc
> :to call this appropriately for {get,set,swap}context.
> :
> :Diffs are at:
> :
> : http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs
> : http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs
> :
> :Compiled and tested on i386, just compiled on alpha.
> :
> :Regarding the floating point state. I didn't change the lazy
> :FP switching, but I did tag each mcontext as to the FP format
> :(in the case of i386), and from where the FPU state came. The
> :FPU state, if present, can come from either the PCB or directly
> :dumped from the FPU. If it came from the PCB, the process
> :owned the FPU in the past but didn't own it at the time the
> :context was retrieved. If it came from the FPU, the process
> :did own the FPU. When restoring FPU state ({set,swap}context),
> :we attempt to leave the FPU state in the same state it was in
> :when the context was originally retrieved:
> :
> : o FPU state from PCB:
> : If the process currently owns the FPU, the FPU state is
> : loaded into the FPU. Otherwise it is copied to the PCB
> : and the next FPU not enabled trap will load it.
> :
> : o FPU state from FPU:
> : If the process doesn't own the FPU, the current FPU owner
> : (if there is one) is dropped and its state saved. The
> : calling process becomes the new owner of the FPU and the
> : FPU state is loaded.
> :
> :I use "process" above, but in reality it is "thread".
> :
> :I also changed the alpha a bit. When delivering signals, it
> :dropped the FPU if it was currently owned. This wasn't done
> :on i386, and I didn't see a reason why it would need to be done
> :for alpha. For i386, signal deliver now includes the FPU
> :context.
> :
> :To Unsubscribe: send mail to majordomo@FreeBSD.org
> :with "unsubscribe freebsd-arch" in the body of the message
> :
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202051438340.87080-100000>