Subject: Re: more funky stuff with kthreads and interrupts
To: None <port-mips@mail.netbsd.org>
From: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
List: port-mips
Date: 05/05/2001 19:32:36
On Fri, 4 May 2001, Jason R Thorpe wrote:

> On Fri, May 04, 2001 at 02:20:53PM +0900, Toru Nishimura wrote:
> 
>  > I'm going to fix the annoyance by inserting savectx() call just prior
>  > to memcpy'ing of PCBs.  This would be a waste of CPU cycle comparing
>  > to add a single line of value assignment.  Introduction of sysproc by
>  > kthread damaged fork semantics somehow, I think.  Comment?
> 
> How about, in proc_trampoline, make a call to _spllower(0) after
> restoring the SR from the trapframe?

  No doubt I'm confused, but I don't quite understand this.  If I
understand proc_trampoline() correctly, the very first thing
proc_trampoline() does is call the "service function".  For a kthread
process, the "service function" is the kthread process start, and will
never return from the jsr.  The kthread process runs at the SPL level that
was in the pcb context when the process starts.  The SPL level is set from
the SR value set by cpu_fork().

  I suppose one could call _spllower(0) before calling the service
function, but that seems to be more overhead than just initializing the
pcb context SR value in cpu_fork() - either by setting it explicitly like
the alpha does, or by doing the savectx() like the i386 and m68k ports.
Also, doing a savectx() would also be more (unnecessary?) overhead than
just setting the SR value in the pcb context.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA