mtd_cpl question

[Bruce R. Montague]

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...


 - bruce