Date: Thu, 5 Sep 2002 22:45:58 +0200 From: Bernd Walter <ticso@cicely9.cicely.de> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: ticso@cicely.de, John Baldwin <jhb@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: ithread preemption Message-ID: <20020905204558.GF13050@cicely9.cicely.de> In-Reply-To: <15735.48281.30915.800894@grasshopper.cs.duke.edu> References: <15735.44660.835003.901974@grasshopper.cs.duke.edu> <XFMail.20020905153533.jhb@FreeBSD.org> <15735.47204.905352.900631@grasshopper.cs.duke.edu> <20020905201443.GD13050@cicely9.cicely.de> <15735.48281.30915.800894@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 05, 2002 at 04:20:41PM -0400, Andrew Gallatin wrote: > > Bernd Walter writes: > > OK - I have some basic understandig problems here. > > > > Why should ithreads ever return to PAL? > > Because PAL initiates the interrupt and creates a stackframe on the > interrupted thread's kernel stack. It then calls the OSes interrupt > vector. In order to restore the state of the world to be like it was > before the interrupt happened, we need to return back to pal. That's clear, but this is not the ithread. ithreads never return - see ithread_loop() in kern_intr.c. > > Why is IPL raised while an ithread is running? > > Pal raises the IPL to the appropriate level to block further > interrupts from the same source before calling into the OS. > > > >From what I understood before the interrupt handler, which is called > > from PAL, just triggers the ithread, block the intline and returns. > > > > The -stable code is easier to understand.. As it was on the C64 =) -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020905204558.GF13050>