Date: Sun, 10 Feb 2002 01:05:58 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: <bde@freebsd.org>, FreeBSD current users <current@freebsd.org> Subject: Re: "fast" interrupt handler threads. Message-ID: <20020210001539.Q3155-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0202082219260.5404-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Feb 2002, Julian Elischer wrote: > Bruce, for the low-level impared such as myself, can you give a quick > precis on teh difference between "fast" interrupt handlers in -current > and 'normal' interrupt handlers. "Fast" interrupt handlers are harder to program and should rarely be used. There are no correctly programmed ones in -current. A correctly programmed one would do not much more than something like: some_sort_of_lock_not_using_mtx(); buf[writeindex++ & mask] = bus_space_read_1(...); some_sort_of_unlock_not_using_mtx(); > Do fast interrupt handlers enter through "trap()" ? No. They are called directly from XfastintrN. A really fast one would be inside XfastintrN. > if they interrupt a user process, do they take on the cred of the running > thread? No. Accessing almost anothing except correctly locked local (static) storage in a fast interrupt handler is a bug. > do they return via doreti() They always do in -current. This is a pessimization (never merged into my version). In -stable, they can only return via doreti if they metamorphose into a normal interrupt handler, which they do in most the few cases where doreti would do something other than just return. Note that it would only do somthing for return to _user_ mode if the fast interrupt handler scheduled a software interrupt (no other interrupts or ASTs can be pending since there must have been none when the fast interrupt occurred, and fast interrupts disable other interrupts). > on returning do they check for ASTs and run userret()? Yes, anything that reaches doreti checks for ASTs and runs userret() if necessary and possible (only for returns to user mode). Hmm, this check seems to be inadequate for fast interrupts. There is no check for rescheduling if the return is to kernel mode. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020210001539.Q3155-100000>