DragonFly kernel List (threaded) for 2005-06
Re: mtd_cpl question
Hi, Mat. re:
> * Instead of setting a bit in e.g. gd_ipending when an interrupt cannot
> be immediately processed, I will take a page from an embedded project
> I did 20 years ago were I used a tail-chasing FIFO to simply record
> the event.
As you point out, this technique has been succesfully
used in many kernels; once the queue overhead is
accepted it is natural. It has often been "reinvented"
under many names. If the event information is recorded
as the address of the code to later execute (by jump
or call) this becomes some variant of the "fork
queue" that is found in, among other things, the
"Cutler kernels", such as NT. This scheme is often
extended to interleave execution of arbitrary
"hard-realtime" routines in the kernel context with
minimal context-switch overhead (pretty much the
entire kernel/SVC functionality can be implemented
this way; essentially the kernel become a real-time
_routine_ dispatcher; processes are scheduled/dispatched
after no more kernel routines can be run).
DEC called such real-time kernel routines "fork
routines" (executed by a "fork dispatcher" processing
a "fork queue"). Presumably this comes about from
the fork-join concurrent program notation that goes
back at least to AOSP around 1960.
Microsoft today uses "deferred procedure" (or DPC,
for Deferred Procedure Call).
IBM called such routines SLIH (Second Level Interrupt
Handler). (I think one of their Unix OSes (probably
running on a VM) also used SLIH routines.
Other names for this technique include "task" (a
horribly confusing term used by Wirth in one of his
experimental systems) and "continuation", used in a
number of systems with a number of slightly different
conotations, some connected to the theoretical notion
more than others.
The very succesful Japanese micro-ITRON systems use
this technique (called "delayed execution service
routine/call", I believe). It's interesting that they
first tried not to use this technique, but got forced
into it somewhere along the line...